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4.4. 


Információéhség : levél- 
áradat" 


Tudástár v2.0O0 — ahol minden 
információ a helyére kerül! 


Ebben a bevezetőben elmesélem, hogyan éltük meg a NetAcademiánál a 
levelezési listák bámulatos felfutását (országos első!), milyen , levéllogiszti- 
kai" problémákkal szembesültünk az idők folyamán, és milyen válaszokat 
adunk most ezekre. Számos kihívásnak kell megfelelnie egy ,korszakalko- 
tó" levelezési megoldásnak, lássuk, lehetséges-e mindez? A levelezés nem 
vész el, csak átalakul! 


Ugye sokan emlékeznek még arra az időszakra, amikor még nem volt email címük? Egészen 
pontosan emlékszem, hogy nekem 1996-ban még nem volt. De nemhiába dolgoztam egy in- 
formatikai élcégnél, egy — akkoriban ritkaságszámba menő - Microsoft Megoldásszállítónál: 
1997-ben lett! (Ekkorra érte utol a történelem önmagát, hisz a nagygépeseknek, Linuxosoknak 
"97-ben már több éves, netán évtizedes emailes múltjuk volt.) 

Kezdetben az ember minden új levélnek örült, hisz az a heti egy darab, ami érkezett, ismerős 
személytől jött. Ahogy egyre több informatikus rendelkezett email-címmel, sokakban felmerült 
egy olyan levelezési megoldás igénye, amely a pont-pont kapcsolatot egy központosított mo- 
dellel váltja fel. Ezt hívjuk levelezési listának. 

Hasonló utat járt be tehát az elektronikus levelezés, mint annak idején a telefon: előbb pont- 
pont kapcsolatban használták (X gróf drótot húzott a szomszéd kastélyba Y báróékhoz), majd 
az érdeklődők számának növekedésével kapcsoló- és átjátszóközpontokat vezettek be. 


A levelezési listák 


Korai, elszórt kísérletek után a NetaAcademia Oktatóközpont is levelezési listákat létesített. Az 
1999-ben indított listákon (SOL, Windows, Exchange stb.) két ,főkolompos" volt (/mICK] és 
fm). Töltögettük is a listát rendesen, tőlünk származott a levelek 8090-a. (Jó-jó, akkoriban csak 
80 tagunk volt, nem pedig 4000, mint ma.) Ma már nulla levél per hó a , teljesítményen", sőt, 
már nem is olvasom kedvenc listáimat. Hová tűnt a kezdeti lelkesedés? 

A taglétszám felfutásával egyszerre rengeteg problémával találtuk szemben magunkat. Az új ta- 
gok -— hogy, hogy nem — minden bíztatás, fenyegetés és mézesmadzag dacára nem tanulmá- 
nyozták át a korábbi évek archívumait, következésképpen egyre gyakoribbakká váltak az olyan 
kérdések, amelyeket én magam már legalább kétszer megválaszoltam, nem is beszélve mások- 
ról, akik szintén. Amikor egy kérdés tizenötödször bukkan fel ugyanazon a listán, az emberben 
elkezd lanyhulni a tettrekészség. 

Nosza, csináljuk tematikus archívumot. 


1. kihívás: az archívum 


A levelek ömlesztett archiválását bármelyik levlista-szoítver el tudja végezni, más kérdés, hogy 
ennek az égvilágon semmi értelme. Még a szabadszöveges keresés sem teszi használhatóvá azt 
a levéldzsumbujt, ami egy ilyen listán szükségszerűen születik. Mire gondolok? Szlengre, rövi- 
dítésekre, utalásokra. Csak egy példa: ha Active Directory problémám van, még akkor sem biz- 
tos, hogy megtalálom az archívumban, ha pontosan tudom, hogy ott van a megoldás, mert mi- 
nimum ezekre a variánsokra kellene keresni: AD, Active Directory, címtár, cimtar — plusz ezek 
félregépelt változatai: Atcive stb. Ez az út járhatatlan, nem is jár rajta senki. 

Egy használható, tematikus archívum fenntartása és bővítése hatalmas munka. 2001-ben volt 
egy vállalkozó, aki pár hónapig dolgozott rajta, de sajnos az eredmények nem , szervesültek be- 
le" a listákba, így gyakorlatilag senki nem talált rá szorgos munkánk eredményére, és minden 
maradt a régiben. Azután Szalontay Zoli (MSHU) készített egy FAO-t, ami szintén nem bővül, 
és szintén nincs szem előtt — tehát megint csak senki nem olvassa el. folytatás a 4. oldalon 
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Avagy hogyan férkőzzünk a Windows 2003 közelébe? 


A Windows 2003 megjelenésével egyidőben a Microsoft egész tankönyvsorozattal rukkolt elő, 
vész hogy segítse a vállalatokat az új technológia hatékony felhasználásában. Ezúttal a Windows-, 
es illetve az IP-technológiát újonnan bevezető cégek szakembereire is gondoltak, ezért született kö- 
zel 30 napnyi tanfolyami anyag. Lássuk, hogyan érdemes feldolgozni ezt a hatalmas tudásmennyiséget! 


ke 5. oldal 
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53 Active Directory elemzés ADUL-cal? 

sa Elmentett lekérdezések (Saved OCuery) 

en vállalatunk címtára tele van szebbnél szebb, jobbnál jobb adatokkal. Hozzá- 
z férünk mindehhez, csupán az a baj, hogy Windows 2000 alatt lekérdezé- 


seinket nem tudjuk elmenteni, így azt minden alkalommal újra és újra be 
kell gépelni. A Windows 2003 ADUC két nagyságrenddel jobb megoldást 
nyújt: a lekérdezések nemcsak elmenthetők, hanem fába is fűzhetők! 


1. oldal 





Csoportos házirendek a indows Server 2003-ban 


Group Policy Management Console 


A korábban bemutatott a Group Policy Management Console gyakorlati oldala 
következik. Végre van egy felhasználói felület a házirendek karbantartására, 
mentésére vagy visszaállítására. A GPMC-vel a beállításokat pár 

kattintással másolhatjuk egy másik házirendbe anélkül, hogy a SYSVOL alatt 
levő könyvtárrendszerben elvesznénk. 





byógyszeresdoboz 
Windows 2000 Server Resource Kit II. 


Az előző számban megjelent általános bevezető és az elsősorban nagyobb 
méretű és komplexitású programok után jöjjön most a sok apró, ám fontos 
gyógyír a Windows 2000 Serverrel vívott ütközetekben szerzett sebeinkre! 
17 ] 





Titokmegosztás ) 
Amit ketten tudnak, nem titok többé. 3 9 
Vagy mégis? ú/ 
Mit tegyünk akkor, ha valamilyen információt úgy kell megoszta- 
ni a résztvevő felek között, hogy azok mindegyikének vagy egy 


meghatározott csoportjának jelen kell lennie az információ rekonstruálásakor? 
Hogyan oldható meg egy titkos adat biztonságos tárolása? 





, A Fermat-kistétel hétköznapi bizonyítása j Ún 
Avagy meddig bírja még az RSA? 1 ] 
E cikk megírásához óriási lökést adott egy magyar fejlesztő, aki nem kevesebbet állít, mint 
hogy elkészítette a világ legjobb titkosítóalgoritmusát, mely ,nem olyan nehézkes, mint az 
RSA, nem támaszkodik az ikerprímekre, következésképp időtállóbb az RSA-nál, ami idővel úgyis 
törhető lesz". Ez az úriember a titkosítóalgoritmusok minimális ismerete nélkül alkotott azoknál jobbat. Nincs is biztosabb alap 
az algoritmusfejlesztében, mint a tárgyi tudástól el nem vakított éleslátás! 


Exchange tippek és trükkök 
Telepítés utáni azonnali tennivalók 


Miután az Exchange szerver telepítése véget ér — azaz a kék csík eléri a 100 99-ot —, ne 
gondoljuk, hogy készen vagyunk. Az igazi munka csak itt kezdődik. Ezután dől el, hogy 
a frissen elkészült szerverünk pár napon belül esetleg megjelenik majd egy open-relay 
tiltólistán vagy egy , igazibb" vírus rövid idő alatt teljesen átveszi tőlünk a hatalmat! 

Jt Hal 
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Mailbox Manager 
Email-takarító gép az Exchange Serverben 


Bár az elektronikus levelek hosszútávú megőrzése általában több mint célszerű, mégis 
érdemes megismerkedni az Exchange Server automatikus levéltörlési szolgáltatásával, a 
Mailbox Managerrel, mert bizony nem minden dolgozó levelezése érdemes a 
megőrzésre, s nem csak levelek pusztíthatják az értékes tárolási kapacitásainkat, 
hanem elavult naptárbejegyzések, a Deleted Items többezer törlésre váró eleme stb. 


07. oldal 


Biztonságos aláíráskezelő alkalmazások 
I. rész: hitelesítések, hitelesítő szervezetek 


Az aláíráskezelő alkalmazás olyan szoftver, mely aláírásokat készít és/vagy ellenőriz. Ilye- 
nek például az Outlook és Outlook Express levelezőprogramok, melyek elektronikus 
levelek aláírását és aláírás ellenőrzését végzik. De ilyen a Word, Excel és PowerPoint is, 
melyek az általuk készített dokumentumok, sablonok és makrók aláírására, valamint a 
mások által aláírt állományok aláírás ellenőrzésére képesek. 


30. oldal 








Portál Paraldigmal 

Negyedik rész — XSLT mint prezentációs réteg 

Nyugodtan mondhatjuk, hogy a modern portálmegoldások alapját az adatrétegtől az 
üzleti logikán át a prezentációig az XML és az XSLT adja. Most nézzük meg, hogyan 
szolgál minket az XSLT-transzformáció, ha az átlagosnál furmányosabb felhasználói 
felületet kell előállítanunk. Ha jól csináljuk, szabványos és az üzleti logikától teljesen 
leválasztott prezentációs réteget kapunk. 


33. oldal 
Exchange 2000 jogosultságállítás kódból 


Az Exchange-fejlesztőknek mind pszichológiai, mind állóképesség szempontjából eddig is jóval 
edzettebbeknek kellett lenniük, mint kollégáiknak. A jogosultságállítás művelete is beleillik eb- 
be a képbe, bár kicsit csalóka, hogy az eleje pikk-pakk, elegáns, csak a vége felé vannak ko- 
moly megpróbáltatások. 


jú. oldal 
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- Tervezési minták a fejlesztésben / KÖSZÖT 
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Módszertanok kora 


Négy év tapasztalata tehát azt mondatja velem: 
olyan megoldásra van szükség, ahol az archívum a 
munka során magától képződik, tematikusan jön lét- 
re, és kiszúrja az új tagok szemét. Ahol tehát az arc- 
hívum és a lista szerves egységet alkot. 


2. kihívás: a levéláradat 


Mindjárt az elején leszögezem: nem a levelek mennyiségével 
van baj elsősorban, hanem azzal, hogy nemhogy a lényeg nem 
ugrik ki a napi 200 levélből, de néha a csevegés kezdetét sem 
könnyű megtalálni. 

A levelezőprogramok , Group by conversation topic" és hason- 
ló csoportosítási megoldásai eleve nem képesek megfelelően 
összerendelni a kérdést a válasszal, ha a válaszlevélből a kliens 
kilopja az eredeti Message-ID-t. (Pedig ez nagyon gyakori eset!) 
Ilyenkor marad a , Re:" , Vá:" ,Fw:" és egyéb jellemzők alapján 
történő azonosítás, aminek totális kudarc a végeredménye. 

Az sem biztos, hogy egy , Re:" szócskával kezdődő levél válasz 
valamire, mert lehet, hogy egy lusta-listatag egy másik szálra 
válaszolva indított új kérdést. És mit szólnak azokhoz a vála- 
szokhoz, amelyekben mindössze ennyi áll: ,ez igaz" vagy még 
tömörebben: , ja". 

Mi marad tehát azok számára, akik teljesen követni kívánják a 
levlistákon folyó munkát? Napi 3-4 óra kőkemény levelezés! 
Tudom milyen ez! Embertelen munka! (Pár hónapig magam is 
csináltam.) 

Felvetődik a kérdés: az informatika hőskorában valóban nem 
vagyunk képesek olyan levelezőrendszert alkotni, ami — me- 
taadatok segítségével — hibátlanul szűrhetővé, elemezhetővé 
teszi a tartalmat? Vajon ez csak úgy valósítható meg, ahogy az 
MSDEV listán teszik? Puszta kézzel XML-tagokat írni a levélbe? 
A kihívás adott: olyan levelezőrendszert kell készíteni, ami le- 
hetővé teszi, hogy ha valaki — mondjuk — csak a kérdésekre kí- 
váncsi (a válaszokra és a csatazajra nem), akkor automatikusan 
előálljon a napi 200-as lista helyett egy napi 8 tételt tartalma- 
zó kivonat. Hibátlanul. 


3. kihívás: anonimitás 

Nem tudom, ki hogy van vele, nálam az a helyzet, hogy min- 
den reggel 8-10 szemét vár az Inboxomban. Viagra, Mortgage 
Rate, ingyenes tonercsere Utah-államban (1434 avenue 365, a 
sarkon túl, jobbra), nem beszélve a nigériai uralkodók tömegéről. 
Hogy találtak meg? Nyilván valahol megjelent publikusan az 
email-címem. Nincs igazi bűnbak, akire ráfoghatnám: te vol- 
tál, aki megszellőztette az email címem. Potenciális jelöltek 
azonban vannak, az egyik veszélyforrás maga a levlista. Talán 
feloldhatatlan paradoxonnak tűnik egy olyan levelezési lista, 
ami nem teszi közszemlére a tagok email címeit — pedig ez 
egyáltalán nem lehetetlen. Sőt! 

Ugyan mi indokolja, hogy a kiküldött levelek bármelyik mező- 
jében valóban a feladó email címe szerepeljen, ha egyszer 
nem is neki válaszolunk, hanem egy központnak küldjük el a 
levelet? 

Olyan megoldásra van tehát szükség, ahol a tagok tetszés sze- 
rinti becenévvel, mégis teljeskörű tagként részt vehessenek a 
levelezésben. 


4. kihívás: hány lista legyen? 5 vagy 55? 

Az 1999-ben megálmodott öt listát (Windows2000, Exchange 
stb.) a terhelés elosztásának igényével a későbbiekben további 
3-4 listával egészítettük ki, amelyek népszerűek lehettek volna, 
de megszokásból mégis mindenki a régi listákon maradt. Be- 
vallom, nem sikerült az MSDEV-listáról leválasztani a 


webfejlesztési témaköröket, a Windows-listáról az SBS- 
kérdéseket, az Exchange-listáról a Sharepoint Portal Server- 
hívőket. Gyakorlatilag semmilyen utólagos szétválasztás sem 
sikerült — az egyetlen OFF-listát kivéve, ahol valójában nem is 
szakmai diskurzus folyik. 

A leválasztás sikertelensége együtt járt az előfizetés finomhan- 
golásának lehetetlenségével is. Ma nem lehet megtenni azt, 
hogy egy témának csak egy részterületére iratkozzon fel vala- 
ki. Csakis a számára érdektelen szemétkupac szétlapátolásával 
jut hozzá ahhoz a kincshez, amire vágyik — legyen ez bármi, 
mondjuk az én esetemben kriptográfia. 

Pontszerű előfizetésre vágyom! Kiáltottam fel valamikor egy 
évvel ezelőtt. S a gondolatot gondolat követte. Megálmodtam 
a hierarchikus listákat. Ezt úgy kell elképzelni, hogy az általá- 
nos Windows lista alatt található — mondjuk — egy Active 
Directory-lista, amely így része is, meg nem is a nagylistának. 
Ha valaki feliratkozik a Windowsra, akkor annak minden ágá- 
ra-bogára előfizetést nyer, és kap napi 200 levelet — illetve ha 
csak a kérdésekre kíváncsi, akkor 15-öt. Ha azonban a hierar- 
chia alacsonyabb pontján iratkozik fel, csak olyan levelet kap, 
ami arra a részterületre vonatkozik. 

Kell-e tovább ecsetelnem az előnyöket? Bárcsak lenne ilyen! 


5. kihívás: validálás, teljesítménymérés 

Honnan tudhatjuk meg manapság, hogy egy válasz helyes 
volt-e? Úgy, hogy megkeressük a hozzá tartozó ,Re:" tárgyso- 
rú levelet, és kiolvassuk belőle, hogy vajon ,köszönöm, sike- 
rült! , vagy ,ez nem jött be" szerepel-e a levél törzsrészében. 
Ezzel megvan egy válasz jósága, igazságtartalma. Ha egy sze- 
mély általában jól válaszol, a lista aktív tagsága tudja, hogy az 
illető válaszait érdemes megfogadni. A passzív, csak időnként 
aktivizálódó tagok azonban ezt már nem tudhatják. Az újak 
meg végképp nem. 

A listákon megjelenő tartalom minőségellenőrzésére jelenleg 
nincs mód. Olyan rendszerre van szükség, ahol a tagság a , Re: 
Hurrá!" és ,Re: Te nem vagy normális!" tudománytalan mód- 
szereken túlmutató véleménynyilvánítási lehetőség birtokába 
jut. Ezzel lehetővé válna a kiemelkedő munkát végző tagok 
egyfajta honorálása (régen bögrét adtunk az okosmondásért, 
de más lehetőségek is léteznek), illetve az is, hogy ha egy prob- 
lémára nem egyetlen, hanem sok megoldás létezik, ezeket fon- 
tosságuk szerint rangsorolva találja meg a következő nemze- 
dék az archívumban. 


6. kihívás: linkgyűjtemény 

Hányszor fordul elő, hogy egy kérdésre egy URL a válasz? 
Legalább az esetek 1099-ában. Még magasabb is lehetne ez az 
arány, hisz a web tele van tartalommal — más kérdés, hogy né- 
ha nem találunk rá. 

A levlistába bedobott link éppúgy elvész, mint bármilyen levél 
— bekerül a szabad szöveges archívumba, ahonnan többé nem 
lehet kikeresni. Mire keressek? Talán erre: http:// ? Vagy netalán 
erre: htm? Hogy lehet megtalálni egy adott kérdésre érkezett 
választ, amiben egy hasznos URL rejtőzik? Sehogy. Kár érte! 
A fenti kihívásoknak megfelelő rendszer létrehozása nem lehe- 
tetlen. Dolgozunk rajta. 


Fóti Marcell 

marcellfgnetacademia.net 

A szerző a NetAcademia vezető oktatója 
MCSE, MCT, MCDBA, MZ/X 
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Avagy hogyan férkőzzünk a Windows 


2003 közelébe? 


A Windows 2003 megjelenésével egyidőben a Microsoft egész tankönyvsorozattal rukkolt elő, hogy 
segítse a vállalatokat az új technológia hatékony felhasználásában. Ezúttal a Windows-, illetve az IP- 
technológiát újonnan bevezető cégek szakembereire is gondoltak, ezért született közel 30 napnyi tan- 
folyami anyag. Lássuk, hogyan érdemes feldolgozni ezt a hatalmas tudásmennyiséget! 


Úgy gondoltuk, nagyban segíti az eligazodást, ha rögtön két 
kategóriába soroljuk a tanfolyamokat, és csak ez után elemez- 
zük azokat tartalmuk szerint. A két fő kategória a következő: 


A Alapozó szint. Ezek a tananyagok azok számára hasz- 
nosak, akik most ismerkednek alaposabban a Windows 
NT alapú világgal, a tarrománymodellel. Kik tartoznak 
ebbe a csoportba? A Windows 98/Me vonalról vagy 
más, nem NT-alapú technológiáról (pl. nagygépes vagy 
Novell-rendszerről) áttérők, a gyakorlati tapasztalatokat 
most gyűjtő friss diplomások. Ide sorolhatók a vállalati 
Helpdesk-részlegek felhasználói problémákat elhárító, 
tűzvonalban lévő munkatársai is, akik feladatkörükből 
adódóan ritkán kényszerülnek mélyebb vizekre evezni. 
Az alapozó szint két részterületre bontható: a Win- 
dows-környezettel és a hálózatokkal kapcsolatos isme- 
retek világára. 

A Rendszermérnöki szint. Ezek a tananyagok általában 
harcedzett rendszergazdáknak készültek. A korábban 
megszerzett elméleti-gyakorlati tudás birtokában már 
,csak" mintegy 12 napnyi tananyag áll előttük. Vannak 
sshortcut", gyorsított tanfolyamok is azok számára, 
akik elegendőnek tartják az újdonságok gyors bejárá- 
sát. A gyorsított tanfolyamokat könnyedén felismerhet- 
jük a címükben szereplő , Updating", vagy — szabad 
fordításban — ,Ráképző" jelzőről. 

Az ,Updating" tanfolyamok közül egy azoknak segít, 
akik NT4-ről ,jönnek", két másik pedig a Windows 
2000-től való eltérést tárgyalja. 


A későbbiek könnyebb áttekintése végett álljon itt egy össze- 
foglaló táblázat a mai naptól létező alapozó és rendszermérnö- 
ki tanfolyamokról: 


Alapozó Windows 2003-tanfolyamok 





á indows-technoló jál (címtái lel stb. 
2274 Managing a Windows 2003 Environment 
Maintaining a Windows 2003 Environment 











2276 ] Implementing a Windows 2003 Server 
Network Inífrastructure 

Implementing, Managing and 
Maintaining a Windows 2003 Server 
Network Inírastructure 

















Rendszermérnöki Windows 2003-tanfolyamok 





4.0 to Windows 2003 








2209 ! 2 nap — Updating Administrator Skills írom Windows 
2000 to Windows 2003 
2210 ! 3 nap " Updating System Engineer Skills from 


Windows 2000 to Windows 2003 
yamok 
yamo 


Plannii 








ng and Maintaining Windows 2003 











2278 5 nap 
Network Inírastructure Ki 
2279 " 5 nap ! Planning, Inplementing and Maintaining 


a Windows 2003 Active Directory 
Infrastructure 


Az alábbiakban a táblázat által felsorolt tanfolyamok tematikái 
következnek. 


2274, Managing a Windows 2003 Environment 


Ezen az ötnapos tanfolyamon felhasználók, csoportok, és 
Windows-erőforrások kezelését sajátítjuk el hálózatos (tehát 
címtáras) és hálózatmentes környezetben. Ez a tanfolyam szol- 
gálhat kiindulási pontként a többi Windows 2003 tanfolyam 
elvégzéséhez. 

Főbb témakörök: Felhasználók létrehozása, csoportba foglalá- 
sa, szervezeti egységbe sorolása, kizárása, engedélyezése, jogo- 
sultságok állítása. Erőforrások (könyvtár, nyomtató) megosztása. 
A szervezeti egységek használata rendszerfelügyeletre: a cso- 
portos házirendek. Erőforrások használatának naplózása (audit). 


2275, Maintaining a Windows 2003 Environment 


Ez a háromnapos tanfolyam a 2274-es folytatásának tekint- 
hető. Bevezetés a Windows-rendszer kezelésének és az adatok 
mentésének fortélyaiba. 

Főbb témakörök: teljesítményfigyelés, monitorozás. Eszközke- 
zelők telepítése, digitális aláírás -ellenőrzése. Lemezkezelés: 
particionálás, és dinamikus kötetek (--RA/D)..Adat- és rendszer- 
mentés, visszaállítás. Katasztrófaelhárítás. Frissítések automati- 
kus telepítése System Update Services-zel. 


2276, Implementing a Windows 2003 Server Network 
Infrastructure 


Ez egy remek kétnapos tanfolyam arról, hogyan kell felépíteni 
egy Windows 2003-hálózatot. A Windows-technológiában já- 
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ratlanoknak érdemes előbb elvégezni a 2274-es, be- 
vezető tanfolyamot, hogy ne okozzon gondot a cím- 
tár, az MMC-konzol és egyéb Windows-specifikus 
technológiák használata. 

Főbb témakörök: IP címzés, alhálózati maszk, CIDR. 
Több alhálózat kialakítása, útválasztás. Automatikus IP-cím 
kiosztása: DHCP, APIPA. Névfeloldási rendszerek: DNS és 
WINS. A leggyakoribb hálózati hibák elhárítása. 


2277, Implementing, Mánaging and Maintaining a Win- 
dows 2003 Server Network Infrastructure 


Ez az ötnapos tanfolyam a 2276-os, IP-alapozó kurzus folyta- 
tása. Itt már tudni kell , mindent" a hálózatról, mivel ez a tan- 
folyam komplex hálózati infrastruktúra kialakítását célozza 
meg. A 2276-os tananyagban kliensoldalról elemzett technoló- 
giák itt teljesednek ki igazán! 

Főbb témakörök: RAS: betárcsázás, virtuális magánhálózatok 
kialakítása, útválasztási protokollok (RIP, OSPF). DHCP: IP- 
tartományok (scope) kialakítása, DHCP-opciók, foglalás 
(reservation), Relay Agent. Névfeloldás: DNS, zóna, zóna- 
transzfer, DNS-rekordok típusai (NS, SOA, MX, A, SRV). Dina- 
mikus DNS. Adatfolyam-titkosítás: IPSEC. 


2208, Updating Support Skills from Windows NT 4.0 to 
Windows 2003 


Ez a háromnapos tanfolyam azokhoz szól, akik NT4-ről térnek 
át — nyilván egyenesen Windows 2003-ra. Ennek megfelelően 
a tematika a Windows 2000-ben felbukkant újdonságokról 
szól: Active Directory, dinamikus lemezek, DDNS, titkosító 
fájlrendszer stb. Hasonlít a korábbi 1560-as tanfolyamra - bár 
annál két nappal rövidebb. 


2209, Updating Administrator Skills from Windows 2000 
to Windows 2003 


Ez a kétnapos, laborokkal teletűzdelt workshop a (minimum) 
MCSA-képesítéssel rendelkezők frissítési tanfolyama. 
Mindenen végigszaladunk, ami csak újdonságnak számít a 
Windows 2003-ban. Nem könnyű dolog két nap alatt ennyi is- 
meretet felszippantani, ezért ez a tanfolyam valóban csak 
MCSA/MCSE végzettségűeknek ajánlható! 

Főbb témakörök: Mi hova lett már megint? Az új és megválto- 
zott rendszerfelügyeleti eszközök áttekintése. A Windows 
2003 Active Directory eltérései a korábbi változattól. Új 
csoportházirend-szerkesztő: a GP Management Console. DNS- 
újdonságok. Parancssori (távJnenedzsment. Az IIS6 felügyele- 
te. Katasztrófaelhárítás. Frissítések automatikus telepítése 
System Update Services-zel. 


2210, Updating System Engineer Skills from Windows 
2000 to Windows 2003 


Ez a kétnapos workshop a 2209-es tanfolyam egyenes folytatá- 
sa. Rengeteg laborgyakorlat van benne, amit csak MCSE kíván- 
hat. Szerencsére létrejött egy tananyag, mely — annyi év vára- 
kozás után — nemcsak elismeri, hanem csokorba is gyűjti azo- 
kat a nem nyilvánvaló hálózati hibákat, amire az Active 
Directory, különösen annak replikációja kényes. 

Főbb témakörök: Active Directory telepítése és a replikáció. 


AD-hibát okozó DNS- és TCP/IP-hibák felfedése és gyógyítása. 
Több AD-erdőből álló hálózat kialakítása. Szoftvertelepítés és 
fejlett biztonsági beállítások kivitelezése csoportos házirenddel 
(GPO). Biztonságosan implementált RRAS. 


2278, Planning and Maintaining Windows 2003 Network 
Infrastructure 


Ez az ötnapos tanfolyam arra szolgál, hogy megtanítsa a — kellő 
elméleti és gyakorlati ismeretekkel rendelkező — hálózatüze- 
meltetőket hatékony Windows 2003 hálózati infrastruktúra 
kialakítására. Kellő előfelkészültséget a 2277-es tanfolyam el- 
végzésével szerezhetünk. 

Főbb témakörök: TCP/IP hálózatok tervezése figyelembe véve 
az útválasztás és a névfeloldás követelményeit. Hatékony és 
hibatűrő DHCP-környezet kialakítása. DNS-infrastruktúra ter- 
vezése belső (Active Directory) és külső (Internet) csatlakozási 
igények figyelembe vételével. Kell-e WINS-szerver? Hova te- 
gyük? Titkosított adatátvitel megtervezése VPN és IPSec beve- 
tésével belső és külső hálózatokon. Hibakeresés és -elhárítás. 


2279, Planning, Implementing and Maintaining a Windows 
2003 Active Directory Infrastructure 


Ez az ötnapos tanfolyam valójában hat- vagy hét napos, de a 
tananyag egy része ,házi feladat". Tehát a tanulás nem ér vé- 
get délután 4-kor, hanem hazafelé a buszon-villamoson is lesz 
mit olvasni. A Microsoft egyszerűen nem mert 5 napnál 
hosszabb tanfolyammal előállni, így született ez a kimerítő tan- 
anyag. Komoly felkészülés nélkül ne is vágjanak bele! 

Ez a tananyag — őszinte sajnálatunkra — egy csomó olyan tud- 
nivalót tartalmaz, amit mindeddig, hivatalos tananyag hiányá- 
ban a NetAcademia AD-mélyvíz tanfolyamán mondtunk el. 
Hiába, ez a világ sorsa, a Microsoft erős abban, hogy utólag 
felismerje az igényeket: 

Előzményként a 2278-as tanfolyamot ajánljuk. 

Főbb témakörök: Az AD logikai és fizikai komponensei. OU- 
hierarchia és GPO-stratégia tervezése, különös tekintettel az 
öröklődési és szűrési (WMI) lehetőségekre. Szoftvertelepítés 
felső fokon GPO-val. A replikáció testreszabása: telephelyek és 
linkek kialakítása. FSMO-szerepek helyének megtervezése, át- 
vitele. Hová tegyünk globális katalógust (GC)? A címtár menté- 
se és szelektív visszaállítása (Authoritative Restore). 

És hogy mindenki elégedetten távozzon az 5. nap végén, egy 
kis NetAcademia-plusz az eredeti irgalmatlan mennyiségű ta- 
nanyagon felül: sémabővítés! 


Remélem nem elbátortalanítottam Önöket, hanem felcsigáz- 
tam érdeklődésüket. De ha mégis az előbbi történt: higyjék el, 
az informatikában bármi megtanulható, hisz csak egy 
emberalkotta világot kell megismerni. A végtelenségnek nyo- 
ma sincs. Hol van ez a biológiától, a matematikától vagy az 
atomkutatástól! 


Fóti Marcell 

marcellfonetacademia.net 

A szerző a NetAcademia vezető oktatója 
MCSE, MCT, MCDBA, MZ/X 


Active Directory elemzés 


ADUL-cal? 


Elmentett lekérdezések (Saved OCuery) 


vállalatunk címtára tele van szebbnél szebb, jobbnál jobb adatokkal. Hozzáférünk mindehhez, csu- 
pán az a baj, hogy Windows 2000 alatt lekérdezéseinket nem tudjuk elmenteni, így azt minden alka- 
lommal újra és újra be kell gépelni. A Windows 2003 ADUC két nagyságrenddel jobb megoldást nyújt: 
a lekérdezések nemcsak elmenthetők, hanem fába is fűzhetők! 


da 


AZ ZESŐ Induljunk ki abból, amit az 
City Active Directory Users and 


Comment Computers (ADUC) jelenlegi 
EN verziója tud. Tetszőleges táro- 
ountry b il e 2 
Coúntív Abbresiattes lón (szervezeti egység stb.) áll- 
Department va az eszköztáron található töl- 
Description csér ikonra kattintva megkap- 
Direct Reports juk az LDAP-lekérdezések ké- 
Display Name szítésének felületét. Itt több ne- 
Division Ez NAB E 

EGval Address hézségi fokozatban állíthatunk 
E-Mail Address (Others) elő egyszerűbb vagy összetet- 
Employee ID tebb lekérdezéseket. A legegy- 
fa MgE LÓ A szerűbbeket néhány pipa be- 
he MT SÉt kattintásával  elkészíthetjük, a 

rst Name 

Generational Stétbő közepesen bonyolultakhoz pe- 
Home Address dig a lap bal szélén látható (tö- 
Home Drive redékes) attribútumlistából vá- 
hedei érzék laszthatjuk ki a szűrőfeltétel- 
Home Phane Nambet (others) ben megadandó mezőket. 
Initials A lehetőségek még itt sem ér- 


International ISON Number 


nek véget. Ha a , Find" listában 
International ISDN Number (Others) 


kikeressük a , Custom Search" 


IP Phone Number lehetősé bad 4 

1P Phone Number (Others) ehetőséget, szabadon szár- 
Job Title nyalhatunk, mivel a megjelenő 
Last Name ablakba tetszőleges LDAP- 


filtert begépelhetünk, például 
kiválogathatjuk azokat az objektumokat, ahol az email-mező 
ki van töltve, legyen az User, Contact, Group vagy bármilyen 
más objektum (lásd később): 


ETKIZMEZTZSZT KET 23 
Find: [Eustom Search -] 


Custom Search , Advanced [ 





Enter LDAP guery: 
(mal-t) 


E Egyedi LDAP-filter megadása a kereséshez 


Szűk keresztmetszetet okoz viszont, hogy egyszerre, egy idő- 
ben csak egyetlen filter lehet aktív, így ha különböző nézőpon- 
tokból kívánjuk elemezni a címtár tartalmát, oda-vissza kell 
cserélgetnünk a filtereket. 

De ennek vége! 








Elmentett lekérdezések 


Indítsuk el az új ADUC-ot! Rögtön szembetűnik a hierarchia 
csúcsán csücsülő ,Saved Oueries" tároló. Vajon mi célt szol- 
gál? 

Nem fogják kitalálni: az eddig veszendőbe ment LDAP- 
lekérdezéseket menthetjük ide! Ez a lehetőség egyébként nem 
várt előnyökkel is szolgál — az ember elkezd gondolkodni, mi- 
lyen lekérdezésekre szokott szüksége lenni? Én hirtelen az 
alábbi funkciók megvalósításának láttam értelmét: 


2 Active Directory Users and Compüters 
I Ele Action Yew Window — Heb 
le -lolnli mal OBIRlnttar ém 
Active Directory Users and Computer: [ Jelszavuk soha nemjarle 3 objects 
j Bullt-in account for admin... 


Bult-in account for gyest... 
This ís a vendor s account ,.. 





Van emad-cimuk 
EEG E suPPORT 38894520.. User 


5 Bf Kiskert.hu 


BO Buttin 


E CI ForcignsecurtyPrincipals 
CI Users 





E Elmentett lekérdezések az ADUC-ban 


A Mely felhasználók engedhetik meg maguknak azt a lu- 
xust, hogy jelszavukat nem újítják meg? (Az ábrán: Jel- 
szavuk soha nem jár le.) 

HA Kik azok, akiket valószínűleg kirúgtak a cégtől, de nem 
szóltak nekünk? (Az ábrán: 30 napja nem jelentkeztek be.) 

JA Kiknek van email-címük? 

A Előkészületben: kiknek NINCS email-címük (Az ábrán: 
Copy of Van email...) 


Az elmentett lekérdezések segítségével immár másodperceken 
belül válaszolni tudok a leggyakrabb kérdésekre, hisz csak rá- 
kattintok a keresésre, és az lefut. 


Műhelytitkok 


Most bemutatom, hogyan készültek az itt látható filterek (az 
email-címes lekérdezést már láttuk). Mekkora erőfeszítésbe te- 
lik megalkotni a , Jelszavuk sohasem..." című filtert? Ha csak 
az LDAP-filtert mutatom, azt mondhatják hogy ilyet élő ember 
nem képes írni: 
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" Elmentett lekérdezések [Saved Nuery] / [/ 


Active Directory elemzés ADUC-cal? 





(s(objectCategory-personl(objectClasszuser][userácc 
ountControt:1.2.840.113556.1.4.803:-55536)) 


El LDAP-filter a soha le nem járó jelszavakról 


S milyen igazuk van! Tényleg nem ember produkálta, hanem 
gép! A lekérdezéstervezőbe ugyanis előre felvették a vélhetően 
leggyakoribb lekérdezéseket, s egy pipa elhelyezésével máris 
választ kaphatunk néhány fontos kérdésre: 


KIE 
tr 


Users ] Eomputers ] Groups ] 


Define the variables of your guery. 
Name JNA] 
Description: I :] I 





E A lekérdezéstervező - kiemeltem az előre elkészített 
lekérdezések csokrát 


Tehát a ,Non expiring passwords" opció kiválasztásával ké- 
szült a , Jelszavuk sohasem..." filter, és hasonló módon alkot- 
tam meg a , 30 napja nem..." szűrőt is. Figyeljük meg a panel 
alján: csak a napok számát kellett kézzel megadnom! 
Természetesen ezt az ablakot is át lehet alakítani , Custom 
Search"-ra, és onnantól teljesen a rendszergazdáé a pálya: 
olyan filtert tákol össze, amilyet csak tud! 


LDAP-filterek példákon keresztül 


Ez persze nem könnyű feladat, ismerni kell ugyanis az LDAP- 
filterek furcsa logikájú, ámbár egyáltalán nem bonyolult szin- 
taxisát. No meg az Active Directory-objektumok attribútumai- 
nak nevét. 

Ha mindössze egy ismert nevű attribútum ismert értékére kere- 
sünk, az LDAP-filter ennyiből áll: 


(Attribútum - érték) 
Például: 
(Description - ,Built-in account") 


Ez a lekérdezés azokat az objektumokat adja vissza, ahol a 
description mező , Built-in account" felirattal kezdődik (a csil- 
lag, mint dzsókerkarakter miatt). 

Akkor kezd bonyolódni a helyzet, ha egynél több attribútumot 
vizsgálunk, vagyis logikai kifejezések építésére lenne szükség. 
Ez ugyanis így néz ki: 


(£(objectclass - user)(cn - Senki)) 


Ez a lekérdezés a Senki nevű felhasználót adja vissza. Az 
LDAP-filterek úgynevezett fordított lengyel jelölést használnak, 
aminek lényege, hogy a műveleti jeleket nem az operandusok 
közé 

141-2 


hanem azok elé írjuk 


$41,152 
Hasonlóképpen (illetve pont fordítva) működtek egyes ősi szá- 
mológépek, ahol először a műveletek operandusait kellett be- 
vinni (mindet!), majd egy műveleti jelet utánaküldve beindult 
a matek. Tehát a fenti képlet két logikai kifejezést kapcsol 
össze, mégpedig ÉS művelettel (ennek jele a £). Példa VAGY 
műveletre: 


(I(objectclass - user) (objectclass - group)) 


Ez a kifejezés az összes user és group objektumot jelenti. 
Most mát könnyedén értelmezni tudjuk a legelső összetett ki- 
fejezést. 


Ez a kifejezés azokat a user objektumokat fedi, akiknél az 
objectCategory attribútum értéke ,person", és a userAccount- 
Control mező értéke 65536. 

Az objectCategory attribútum segítségével lehet különbséget 
tenni számítógépfiók és felhasználó között. (Mivel egyébként 
mindkettő user típusú objektum!) A userAccountControl attri- 
bútum pedig egy bitmező, amelyben az egyes bitek a felhasz- 
nálón bepipálható különböző opciókat jelentik. A 65536 ezek 
szerint az a bit, ami a jelszóváltást kikényszeríti, míg más bitek 
a felhasználó letiltására (Disabled — 512) és egyéb funkciókra 
szolgálnak. 


Mi az az 1.2.840.113556.1.4.803? 


Az attribútum ISO-azonosítója (OID), amit ki is lehet fejteni: 
1-ISO 

2 

840 -— USA 

113556 - Microsoft 

és itt — dokumentáltság híján -— el is veszítjük a fonalat... 


Milyen attribútumok léteznek? 


Az Active Directoryban minden objektum olyan attribútumok- 
ból áll, amilyeneket a séma megenged, vagy méginkább: dik- 
tál. Emiatt a legfontosabb információforrás a séma. Az MSDN 
Libraryban a séma teljes dokumentációja megtalálható, be- 
leértve a fent emlegetett bitszörny, a userAccountControl egyes 
bitjeinek jelentését is. 

Picit gyakorlatiasabb megközelítési mód a try-and-fail mód- 
szer, amikor próbálkozásos módszerrel találjuk ki egy attribú- 
tum belső nevét és értékkészletét. Ehhez a Windows CD-n, a 
SUPORTWTOOLS mappában található, és onnan telepíthető 
LDP.EXE illetve ADSIEdit MMC-konzol használható. 

Az eljárás menete: kiszemelünk egy mezőt (mondjuk a 
Descriptiont), és kitöltjük messziről világító tesztadattal (pl: 
aaaaaaaaaaaaaaaaa). Ezután LDP.EXE-vel megnézzük, hogy 
hol vakít ez az adat, s leolvassuk az attribútum valódi nevét, 
ami ebben az esetben szintén Description. Ugyanakkor az 
Office mező belső neve physicalDeliveryOfficeName, amit ha 
nem tudunk, az összes erre épülő filter hibásan fog működni! 


Fóti Marcell 

marcellfonetacademia.net 

A szerző a NetAcademia vezető oktatója 
MCSE, MCT, MCDBA, MZ/X 


Kapcsolódó NetAcademia tanfolyam: 
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Lsoportos házirendek a 
Windows Server 2003-ban 


Group Policy Management Console 


A korábban bemutatott a Group Policy Management Console gyakorlati oldala következik. Végre van 
egy felhasználói felület a házirendek karbantartására, mentésére vagy visszaállítására. A GPMC-vel a 
beállításokat pár kattintással másolhatjuk egy másik házirendbe anélkül, hogy a SYSVOL alatt levő 


könyvtárrendszerben elvesznénk. 


Házirendek karbantartása 


A GPMC egyesével, vagy csoportosan is lehetővé teszi a házi- 
rendek egyszerű mentését és visszaállítását. A mentés és az 
export funkció megegyezik, de a visszaállítás és az import 
közt nagy különbség van. A visszaállítás a házirend azonosí- 
tójához, a GUID-hoz kötött, tehát visszaállítani csak ugyano- 
da tudunk, míg az import funkció lehetővé teszi, hogy egy 
meglevő házirendre ráhúzzuk egy másik beállításait, függetle- 
nül a GUID-tól. Importálni nemcsak ugyanabban a tarto- 
mányban levő házirendekből lehet, hanem kívülről, akár má- 
sik erdőből (Forest) is. 

Ezen kívül másolni is lehet a házirendeket. Másoláskor a 
GPMC létrehoz egy üres házirendet, és abba teszi a 
beállítsokat, míg az import egy meglevő házirendre képes csak 
ráhúzni a beállításokat. Az egyes műveleteket részletesen is 
láthajtuk a későbbiekben. 


Házirendek mentése és visszaállítása 


A GPMC a házirendek mentésekor a kiválaszott házirendekről 
másolatot készít egy előre megadott könyvtárba, és a mentés- 
sel együtt néhány fontos információt is megjegyez róluk. 

A mentést számos módon elkészíthetjük. Menthetjük a házi- 
rendeket egyesével, vagy együttesen is: 


1. Ha minden házirendet egyszerre szeretnénk lementeni, 
a Group Policy Objects konténeren állva a gyorsmenü- 
ből a Back Up all... parancsot kell választani, ahogy az 
alábbi képen is látszik. 


TET ENEST-T ES] 
ÚZ le Action Yew Wöndom He Jelzi 
(e s]lElnielBlé 


oup Pokey Management 
Forest: hell.net 
E (gy Domans 
E Éj hettnet 
ÉS Default Domain Poley 
A (g) Domain Controllers 


tb Default Domain Controler 
lsz e. 


8 Defaut 
3 Wii Fiters  HMöntöge Backups:i 
03 szes Vew 
(a Grovo Polky Modelr New Window from Here 
3 Group Polcy Results ——————— 
Refresh 


Help 











Group Policy Objects in hell.net 
Contents ] Delegaton ] 
[Name fGPOStatus — [WMiFaer 


49 Defaut Domain Controlars Policy. Enabled None 
5 Default Domain Pobcy Enabled None 





Bzdkup al GPOs 
B Az összes házirend mentése egy kattintásra 


2. Lehetőség van több házirend mentésére, az összes há- 
zirend mentése nélkül. Ehhez a Group Policy Objects 





konténeren állva a jobb oldalon levő Contents ablak- 
ból SHIFT vagy CRTL segítségével ki kell választani a 
mentésre szánt házirendeket, majd a gyorsmenüből a 
Back Up... parancs segítségével indíthatjuk a mentést. 






83 Ela Acton Mem Window Help 
e s ]almialé 












Ego Poky objedtő) " [ 
B Kiválasztott házirendek mentése egy menetben 


3. Ha egyetlen házirendet szeretnénk elmenteni, megte- 
hetjük azt az előző pontban ismertett módon, vagy úgy, 
ha jobb egérgombbal kattintunk a bal oldalon levő ab- 
lakban a kiválsztott házirenden, majd a Back Up... pa- 
rancsot választjuk. 














. zlol2d 
3 Ele  Adton Wew Window He (zata 
c 5slolniaeix Bé 


J Restricted Users 
Scope ] Detais ) Settngs] Delegaton] 


Link 
Dizplay nics in this Jocator  [helner 57] 
Ie folowing stes. domains, and Us are ínked to thiz GPO: 

[docA a /Ertoced [nk Enabied 





OD Egyetlen házirend mentése 


Bármelyik helyről indítjuk is a mentést, a megjelenő ablakban 
a mentés helyét kell megadnunk, majd a Backup gombra kat- 
tintva a mentés hamarosan elkészül. 


A mentés a következőket tartalmazza: 
TA Házirend-beállításokat 
HA A házirenden beállított jogosultságokat 


. MPg-£N0Z7 IaNIa5 SMOPUIM PR YapPNAIIZET S0JI0d05J / 


aj0s5u0oj juawmasenem ÁJrrog dnoig 


- Group Policy Management Console / Windows 


Csoportos házirendek a Windows Server 2003-ban 


10 


HJA A WMI-szűrő linkjét — de magát a WMI szűrőt nem! 
TA A házirend és a tartomány azonosítóját (GUID) 


A mentés tartalmazza a SYSVOL alatt levő fájlokat és a házi- 
rendről az Active Direcoryban található információkat is. Ami a 
házirendhez tartozik, de nem a SYSVOL könyvtár alatt találha- 
tó — ilyen például a WMI szűrő is — nem kerül bele a mentésbe. 
A mentés a lementett házirendnek minden alkalommal ad egy 
egyedi azonosítót, és létrehoz egy ugyanilyen nevű alkönyvtá- 
rat a mentésre kijelölt könyvtárban, ebben a házirendeket 
egyesével tárolja. 

A mentésre kijelölt könyvtárban a manifest.xml fájlban tárolja 
a GPMC a házirendek mentési idejét és az azonosítókat. Ez- 
zel lehetővé válik, hogy egy-egy házirendről több, különböző 
időpontokban készült mentést tároljunk ugyanabban a könyv- 
tárban. 

Minden házirendhez tartozik egy XML-fájl, amelyből mindent 
megtudhatunk az adott házirendről. 


A GPMC-vel készített mentések kezelésére is van egy felhasz- 
nálói felület, amelyet a Group Policy Objects konténeren áll- 
va a gyorsmenüből a Manage Backups parancs segítségével ér- 
hetünk el: 


E A mentések kezelése 


Innen lehet nyomonkövetni a mentéseket, vagy bármely men- 
tett házirend beállításait is innen tudjuk megnézni a View 
Setting... gombra kattinva. 

A visszaállítást is indíthatjuk innen a Restore gombra kattintva. 
Csak innen tudjuk visszaállítani azokat a házirendeket, ame- 
lyeket előzőleg letöröltünk. 

Meglevő házirendek előző állapotba való visszaállítását indít- 
hatjuk a Group Policy Objects konténerben a házirenden állva 
a gyorsmenü Restore form Backup... parancsával. 


Akár törölt házirendet állítunk vissza, akár csak egy előző vál- 
tozathoz szeretnénk visszatérni, a visszaállítás megőrzi a házi- 
rend eredeti GUID-ját, és a következőket állítja vissza: 


HA A házirend beállításait 
A A házirenden állított jogosultságokat 
TA A WMI-szűrő linkjét 


NEM állítja vissza a GPMC a linkeket, amellyel a házirendet 
konténerekhez kötjük. Ha előzőleg törölt házirendet állítunk 


u or king vith vi ndoms 





vissza, magunknak kell gondoskodni arról, hogy a megfelelő 
konténerhez kössük a visszaállított házirendet. 

Amikor egy törölt házirendet állítunk vissza, nemcsak a házi- 
rend GUID-ot állítja vissza a GPMC, hanem a verziószáma is 
ugyanaz lesz, mint a mentésben. 

Ha viszont egy meglevő házirendet állítunk vissza egy előző 
változatra, a GPMC a meglevő házirend verziószámát eggyel 
megnöveli annak érdekében, hogy minden más tartományve- 
zérlő újként fogadja el, és az ügyfélszámítógépek is újabbnak 
tekintsék a meglevőnél. 


Házirendek exportja és importja 

Az export megegyezik a mentéssel. Nincs is külön parancs rá. 
Az előzőleg lementett házirendeket tudjuk importálni. A 
visszaállítás és az import közt az a különbség, hogy az import 
csak meglevő házirendre lehetséges, és az import nem foglal- 
kozik az importálandó házirend GUID-jával. Ezért nemcsak 
ugyanabban a tartományban lehet importálni, hanem más tar- 
tományból vagy akár másik erdőből származó származó men- 
tést is importálhatunk! 


Az importálás folyamata a következő: 

1. Létre kell hozni egy üres házirendet a tartományban, 
vagy ki kell választani egy meglevőt, amelyre importál- 
ni szeretnénk. 

2. Group Policy Objects konténeren a létrehozott vagy 
kiválasztott házirenden állva a gyorsmenüből az Import 
settings parancsot kell választani. Ezzel elindul egy va- 
rázsló. 

3. A varázsló figyelmeztet, hogy a meglevő házirend beál- 
lításait az import törölni fogja, és lehetővé teszi a ko- 
rábbi házirend mentését, mielőtt az importálás megtör- 
ténne. 


TIE 


Backup GPO 
Backup the existing settings ín this GPO. 








E Házirend mentése az import előtt 


4. Ezután meg kell adni, mely könyvtárban található a 
mentés, ahonnan importálni szeretnénk. 

5. Utolsó lépésként kiválaszthatjuk, melyik házirendet 
szeretnénk importálni. Itt lehetőségünk van import előtt 
még egyszer megbizonyosodni arról, hogy a megfelelő 
házirendet importáljuk-e az ablakon található View 
Setting gombra kattintva. 


technet 


Import Settings Wizard 


Source GPO 
Select the GPO from which you want to import settings. 











Az importálandó házirend kiválasztása a mentett házi- 
rendek közül 


Figyelem! Az import nem érinti a házirend-jogosultságokat, a 
WAMI-szűrő linket, sem pedig a házirend linkjeit a konténerek- 
hez! Ezek a beállítások az 1. pontban létrehozott vagy kivá- 
lasztott házirendben levő beállításokat követik. A folyamat csu- 
pán a házirend beállításait importálja! 


Házirendek másolása 


Leginkább az importhoz hasonlít, a fő különbség a kettő közt, 
hogy a másolás létrehozza azt a házirendet, amibe másolja az 
eredetit, míg az import egy meglevő házirend esetén lehetsé- 
ges. 

A másolás lépései a következők (egy tartományon belül): 

1. kiválasztjuk a másolni kívánt házirendet a Group 
Policy Objects konténerben, rajta jobb egérgombbal 
kattintunk a menüből a Copy parancsot választjuk. 

2. Ezután a Group Policy Objects konténeren állva 
megint jobb gomb, majd Paste. Ennek hatására a követ- 
kező ablak bukkan elő: 


ász] 





B Jogosultságok beállítása a másolás során 


3. Itt választhatunk, megtartjuk-e az eredeti házirend jo- 
gosultságait vagy sem. Az OK-ra kattintva megtörténik 
a másolás. 


Házirendek másolása egy tartományon belül, vagy tartomá- 
nyok közt illetve erdők közt is lehetséges. Mivel a másolás for- 
rásként az Active Directory objektumait használja (nem pedig 
a mentett állományokat, mint az import), tartományok illetve 
erdők közt a másolás akkor lehetséges, ha a forrás és a cél közt 
trust kapcsolat létezik. 

Amikor egy tartományon belül másoljuk a házirendet, a VVMI- 
szűrő linket is másoljuk, ugyanakkor ez tartományok vagy er- 
dők közti másolásnál nem lehetséges. 

Házirendek másolásánál lehetőség van megválasztani, 
megtartjuk-e az eredő házirend jogosultságokat, vagy az alap- 
értelmezett jogosultságokkal hozzuk létre az új házirendet. Ez 


at 
-nhnet E 6 JT átal lű 


is egy különbség az importhoz képest, hisz az import 





nem veszi figyelembe az eredő házirend jogosultsági 
beállításait. 


Házirendek modellezése 


A Windows 2003 lehetővé teszi a házirendek hatásainak vizs- 
gálatát, mielőtt még elterjesztenénk őket az éles környezetben. 


Ezt Resultant set of Policies (RSoP) — Planning Mode-nak hív- 


juk, amit a GPMC-ben Group Policy Modellingre kereszteltek. 


Ez a funkció csak Windows 2003 Active Directory esetén ér- 
hető el, ilyenkor a GPMC-ben látható egy Group Policy Mo- 


delling konténer, amelyen jobb egérgobbal kattintva a menü- 


ből indítható a tervező-varázsló. 


policy settings for a selected user (or a container with user 
information) and computer (or a container with computer information). 


E Házirend hatásának tervezése - 1. lépés 


1. Itt először meg kell határozni egy Active Directory kon- 
ténert vagy felhasználót a házirend felhasználói beállí- 
tásaihoz, majd a házirend számítógéphez tartozó beál- 
lításaihoz is választani kell egy konténert — vagy egy bi- 
zonyos számítógépet. 


A fenti képen látható, hogy a TS konténerben levő felhaszná- 
lókhoz a Computers konténerben levő gépeken fogjuk szimu- 
lálni a beállításokat. Tehát azt tudhatjuk meg, hogy milyen 
házirendbeállításokkal találkozik a TS konténerben levő fel- 
használó, mikor egy Computers konténerben levő számítógép 
előtt ülve lép be a tartományba. 


2. A [következő lépésben tovább finomíthatjuk a modelle- 
zést. Lehetőség van lassú kapcsolat (pl. dial-up) és 
Loopback-policy modellezésére is, illetve megadhatjuk 
az AD telephelyet (Site) is. 

3. A következő két ablakban megadhatjuk, mely csopor- 
toknak legyen tagja a felhasználó, illetve a számítógép. 
Tudjuk, hogy a házirendek hatáskörét konténereken be- 
lül AD-csoportokkal szűkíthetjük. 

4. Végül a WMI-szűrőket is beállíthatjuk, hogy melyek le- 
gyenek érvényben a modellezéshez, és melyek ne. 
Alapértelmezésben a kapcsolt WMI-szűrőket figyelem- 
be veszi a modellező. 

5. A varázsló ezután összegzi a megadott információkat: 


b Md Ea ER W B... WA 
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JE 





Group Policy Modeling Wizard 





Summary of Selections F 
The ist contains the selections you made in this wizard. 
Ész 





To make changes to your selections, cick Back. To process the simulation, csck Next. 













Selection 
User container 0U-TS DC-hellDC-net 
Computer container CN:Computers. DCshellDCznet 
Slow network. simulation No 


Seltings 


Loopback mode (None) 

Site name É DefaultFirst-SiteName 
User security groups (Not specified) 
Computer security groups (Not specifed) 


MI fiters for users 
"WMI fiers for computers 


" (AI linked WMI filters egual TRUE) 
(AN linked WMI filters egual TRUE) 


brave.hellnet Browsse... 
l 








IRT] 





B A tervező varázsló összefoglaló oldala 


A tervezés utolsó lépéseként megadhatjuk, mely tartományve- 
zérlőhöz forduljon a GPMC az elemzés során. 

Az elemzés végeredménye azonnal megjelenik a GPMC-ben, 
amelyből megtudhatjuk, pontosan mi lesz az adott konténer- 
ben levő felhasználók és gépek beállítása. 


Házirendek utólagos vizsgálata 


A Windows 2003 lehetővé teszi a házirendek utólagos vizsgá- 
latát is. Ez a Resultant set of Policy (RSoP) — Logging mode, 
amit a GPMC-ben Group Policy Results néven találunk. 
Csakúgy, mint a tervezésnél, itt is varázslót kell indítani — eh- 
hez a jobb egér gombbal kattintsunk a GPMC Group Policy 
Results konténerén, majd onnan Group Policy Results 
Wizard... parancsot válasszuk. 





Computer Selection 
"You can view policy settings for this computer or for another computer on this network. 
Ca 


Select the computer for which you want to display policy settings. 
c mrcsmsie] 
C Another computer: 


EEG SES ESENTET EGG 





IT Do not display policy settings for the selected computer in the results (display user policy 
settings ony) 





c Back Next? 


ese] 
I3 Számítógép kiválasztása az elemzéshez 


Első lépésként ki kell választanunk egy számítógépet, amelyet 
elemezni szeretnénk. A tervező móddal ellentétben ez a va- 
rázsló közvetlenül az itt kiválasztott számítógéphez fog kap- 
csolódni. A házirendek hatását akkor is meg tudjuk vizsgálni, 
ha Windows 2000 Active Directoryval dolgozunk, de ebben 
az esetben is Windows XP vagy Windows 2003 operációs 
rendszer szükséges az elemzés futtatásához. 


A következő ablakban kiválaszthatjuk azt a felhasználót, akire 
az elemzést le szeretnénk futtatni. (Számítógépet mindenkép- 
pen választanunk kell, felhasználót nem kötelező.) 


Group Policy Results Wizard íz XI 


User Selection p 
You can view policy settings for any users of the selected computer. 
Él 





7 Display policy settings for: 
c merre 


€C Select a specific user: 
HELLVAdmiristrator 


C Donat display user policy settings in the results [display computer poliey settngs only) 


men ] 











a Felhasználó választása az elemzéshez 


Az utólagos vizsgálatot konkrét esetekben, például hibás mű- 
ködés feltárásakor használhatjuk. 

Az eredményt rögtön láthatjuk a konzolban, külön riportot 
hozhatunk létre, vagy megnézhetjük a beállításokat. 


GPMC műveletek parancssorból 

A házirendek mentése, visszaállítása, másolása, importálása el- 
végezhető parancssorból is, a GPMCYscripts könyvtárában ta- 
lálható előre főzött scriptek segítségével. 







Házirendek mentése 


Minden házirend mentése — 





BackupAlIGPOs.wsf 














. Házirendek visszaállítása RestoreGPO.wsíf 

Minden házirend visszaállítása RestoreAlIGPOS.wsf üg 
Házirend másolása CopyGPO.wsf ülj 
Házirend importálása Import GPO.wsf efa 





A scriptek a Windows Scripting Hosttal használhatóak, tehát a 
parancssorban a következő módon használhatjuk őket: 


cC:Wprogram filestgpmciscriptszcscript CopyGPO.wsf 


A? opcióval futtatva a scripteket megtudhatjuk a kapcsolóikat. 


Dorner Csilla 
dorner.csillagonetacedemia.net 


Kapcsolódó NetAcademia tanfolyam 
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Windows 2000 Server Resource Kit II. 


Az előző számban megjelent általános bevezető és az elsősorban nagyobb méretű és 
komplexitású programok után jöjjön most a sok apró, ám fontos gyógyír a Windows 2000 Serverrel 


vívott ütközetekben szerzett sebeinkre! 


Elöljáróban fontosnak tartom hangsúlyozni, hogy többszáz al- 
kalmazásról van szó, így csak erősen szubjektív mazsolázást 
tudok elkövetni, aki többet szeretne, turkáljon bátran! 


Egy kis áttekintés újra 

A telepítés után ezek az eszközök egy (lehet, hogy csak szá- 
monmra) kissé furcsa logika szerint a Resource Kit programcso- 
portban a Tools pont alá (ami egyenértékű a 9oSystem- 


root? Resource Kit mappa megnyitásával) vannak besorolva, 
ahol a kategóriák a következők: 


Computer Management Tools 
Debugging Tools 

Deployment Tools 

Desktop Tools 

Diagnostics Tools 
Documentation 

File and Disk Tools 

Internet Information Services 
Network Management Tools 
Performance Tools 

Remote Administration Scripts 
Scripting Tools 

Security Tools 


BBBBBBBBBBBBEB 


Érdemes megemlíteni még ugyanebből a programcsoportból a 
Tools Help menüpontot, ahol a részletes segítség mellett az al- 
kalmazások azonnali elindítására, kipróbálására is van közvet- 
len lehetőség. 


Ebben a részben a Computer Management Tools csoportból 
két, minden üzemeltető számára alapvetően fontos téma körü- 
li alkalmazásokat tallózzuk, ezek pedig a szervizek és a re- 
gisztrációs adatbázis témakörök. 


Szervizek kezelése 


A parancssori eszközök közül legyen az első az egyszerű 
Delete Service (delsrv.exe), amellyel manuálisan törölni (tehát 
végleg eltávolítani) tudjuk a szervizt és vele az összes összete- 
vőjét. Több szolgáltatást nyújtó program a Service Installer 
(instsrv.exe), mely szintaxisa így néz ki: 






INSTSRV cservice 
[-a cAccount 


Tehát nem csak faragni tudunk alkalmazásokból szervizeket, 
hanem eltávolítani is képes ezeket a segédprogram, valamint 
jogosultsághoz is köthető a szerviz futása. Következő alany a 
Command-line Service Controller (netsvc.exe), amellyel lekér- 
dezéseket hajthatunk végre (pl. guery és list), de az alapparan- 
csokat is ismeri (start, stop, continue, pause). 


tat it. w i 


Eddig ugyan még nem említettem, de megfelelő jogosultság 
esetén gyakorlatilag az összes idevágó parancssori segédprog- 
ram használható más gépeken regisztrált szervizek kezelésére. 
Az alábbi példa az összes létező szervizt és eszközt kilistázza 
egy másik gépről, fájlba. 


netsvc VWmasikgep /list 5: masikgep.txt 


A Service List (sclist.exe) viszont egyszerű eszköz: csak kilistáz- 
za a jelenleg futó/leállított szervizeket. Van még egy Service 
ACL Editor nevű eszközünk (svcacls.exe), ami mégsincs, mert 
ugyan a dokumentációban benne van, de valahogy mégis ki- 
maradt [2269875], helyette a Subinacl /service parancs hasz- 
nálható szervizekkel kapcsolatos jogosultságok delegálására, 


így: 





Továbbmenve, egy igazán említésre méltó parancssori holmi- 
ról is szeretnék szólni, ez pedig a Service Controller Tool 
(sc.exe), ami elrettentően univerzális, megszámoltam: 21 para- 
métere van, de egy-egy paraméteren belül is van még további 
élet. Az összes eddigi műveletet ismeri, valamint a grafikus fe- 
lületen beállítható opciókat (pl. mit csináljon leállás esetén, 
milyenek a függőségi viszonyok, stb.) is tartalmazza. Aki szere- 
ti a parancssort (rossz ember nem lehet 0) ezzel mindent meg 
tud oldani a szervizekkel kapcsolatban. 


A grafikus felületűek között található a népszerű, ugyan kevés- 
sé variálható, ám a legtöbb célra bőven megfelelő Service 
Installation/Remove Wizard (srvinstw.exe), amellyel másod- 
percek alatt végezhetünk a , Csináljunk már szervizt az alkal- 
mazásból!" feladattal. 
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Végül essen szó részletesebben egy finom eszközről, 
a Service Monitoring Tool-ról, amely maga is egy 
szerviz. Ha van egy bármilyen Outlook változat kéz- 
nél, és egy Exchange Server a közelben, ez az eszköz 
e-maileket küld nekünk ha leáll/elindul egy-egy kije- 
lölt szolgáltatás. Ahhoz hogy használhassuk, kövessük a követ- 
kező lépéseket. 

HA Másoljuk be az svcmon.exe-t a winntvsystem32 map- 
pába. 

TA Futtassuk parancssorból az smconfig.exe-t, ami a prog- 
ram beállításainak varázslója. 

A Az üdvözlő képernyő után adjuk meg a leendő svcmon 
szervizzel kapcsolatos jogosultságokat, a levelező 
kliens profiljának nevét, valamint az értesítendő célsze- 
mély vagy célszemélyek pontosvesszővel elválasztott 
címét. 

HA A következő képernyőn jöhet a figyelni kívánt gép és 

szerviz(ek) neve (max. 99 db lehet), a figyelési időköz 
hozzáadása, és végeztünk is. 


!  SrvMon - Service Monitor Configuration Wizard 





Please select the service that you would like to monitor 


then click Add Service to add ít to the list. 
MachineName ——— TESTSRV2 j 
Service 


Polina Interval (3). [500 
[7 Restartit if stopped [7 Reboot server if restart failed 


TESTSRV2: World Wide Web Publishit 
Remove ] 


Ciick Finished to complete the configuration. 

















c Back Finish 


face 


E A www szerviz változásával kapcsolatos beállítások 





Amennyiben látni szeretnénk, mit csinál a program, vagy ép- 
pen hibakeresésre van szükség, engedélyezzük a naplózást 
ezen kulcson az alapértelmezett Enabled F(alse) helyett a 
T(rue) beírásával, valamint ugyanitt a naplózási szint beállítá- 
sával (1-7-ig, az utóbbi a legrészletesebb): 


HKEY LOCAL MACHINEMSoftwarelMicrosoftiResKitV 
Service Monitoring ToolNYLogging 


A regisztrációs adatbázissal kapcsolatos eszközök 

Ebben a részben is elsősorban parancssori eszközökkel foglal- 
kozunk, mégpedig először a Registry Find (regfind.exe) kerül 
terítékre. Ez az eszköz nevével ellentétben nemcsak keres (és 
talál) hanem cserél is, ha kell, ami néha a GUI-n történő vad 
kattintgatás helyett jól jöhet. Az alábbi parancs például kicse- 
réli az eddig a 192.168.0.7 értékkel a TCP/IP protokoll tulaj- 
donságaiban szereplő DNS szerver IP címét egy másikra: 
regfind -p HKEY LOCAL MACHINENSYSTEMV 


$ currentcControlgsetiServicesíTcpipilparameters 
$ 192.168.0.7 -r 192.168.0.221 





Ha szükséges, vesszővel elválasztva több címre is ki tudjuk 
cserélni az eredeti címet, valamint fontos tudnivaló még, hogy 
ez a parancs a helyi gépre vonatkozott, de van lehetőség távo- 
li gépen is változtatni a 








opcióval, persze a jogosultságnak itt is meg kell lennie. Az esz- 
köz népszerűségét bizonyítja valószínűleg az is, hogy a Win- 
dows .NET Server Beta 3 Reviewer"s Guide szerint az új szer- 
ver operációs rendszerben benne lesz gyárilag. (Más kérdés, 
hogy konkrétan a regfind.exe az RC-kben valahogy mégsem ta- 
lálható meg, viszont több, eddig csak a Resource Kit-ekben 
megjelent komponens annál inkább, no de majd a véglegesnél 
kiderül minden.) 


Valószínűnek tartom, hogy a Registry Backupot (regback.exe) 
keveseknek kell bemutatni. Már csak azért is fontos ez az esz- 
köz, mert ugyan az általános mentésre használt NTBackup 
System State opciójával elmenthetjük a regisztrációs adatbázist 
is (és persze vissza is tölthetjük), de sajnos külön nem, csak az 
általában többszáz MByte-os adathalmazzal (címtár és egye- 
bek) együtt. Ezzel a kis programmal viszont orvosolhatjuk a pá- 
ni félelmet, ami a registryhibák esetén jön elő az ember fiából. 
Lehetőség van kulcsok, értékek, avagy komplett ágak mentésé- 
re is. Használata egyszerű, két lépcsős: először a registryágak- 
ról készül mentés öt állomány formájában az általunk mega- 
dott helyre, majd manuálisan a ,-u" kapcsolóval és a menteni 
kívánt user SID-jével a felhasználó profilja (ntuser.dat) is le- 
menthető. A [0318149] tudásbázis cikkben található részletes 
leírás egy időzített napi registry mentésről. A Registry Backup 
párja a Registry Restore (regrest.exe). Ezt használhatjuk 
visszaállító eszközként, a user profillal kapcsolatos részeket 
ezzel is külön lépésben lehet kezelni. 

Bizonyos esetekben hasznos eszköz a Registry Size Estimator 
(dureg.exe), amely akár gyökérkulcsonként is képes kiszámol- 
ni a regisztrációs adatbázis méretét, vagy éppen kereshetünk is 
vele tetszőleges sztringeket. 


LL ST szavat Kora 


Prog o 
TS telj i 


, MACHINE 


otal Registry data 


Find the si 
Find the si 
Find the si 
Find the size LOCAL MACHINE 

(ae ESÖ ZÜL NAT TT RT ELTE AE NT] 


E Ez még nem olyan kövér, maradhat. 


Ha már itt tartunk, megemlíteném a Registry Scan 
(scanreg.exe) alkalmazást, amely segítségével jóval alaposabbá 
és látványosabbá válhat a keresés illetve annak eredménye, 
mint a grafikus felületen. 


Gál Tamás, MCSE 2000 
gtamasatjszki.hu 


litokmegosztás 


Amit ketten tudnak, nem titok többé. 


Vagy mégis? 


Mit tegyünk akkor, ha valamilyen információt úgy kell megosztani a résztvevő felek között, hogy azok 
mindegyikének vagy egy meghatározott csoportjának jelen kell lennie az információ rekonstruá- 
lásakor? Hogyan oldható meg egy titkos adat biztonságos tárolása? 


A titokmegosztás nem új dolog. Bizonyára sokunknak van em- 
léke valamelyik kalandos regényből néhány kalózvezérről, 
akik egymásban nem bízva közösen ássák el a rablott kincset. 
Mit tesznek ezután? Tételezzük fel, hogy hárman vannak. A 
három vezér a kincs környezetéről egy térképet készít. A térké- 
pet három részre vágják, és mindenki eltesz egy darabot. Sok 
év után az utódaik öröklik a térképdarabokat. Ha az utódok 
meg akarják keresni a kincset, a következő problémákkal ke- 
rülhetnek szembe: 

1. Nem találják meg egymást, vagy valamelyik térképda- 
rab elvész. Kétséges, hogy a maradék darabokból a 
kincs helye meghatározható lenne, hiszen a három ka- 
lóz éppen azért (és úgy) darabolta fel a térképet, hogy 
egymásra legyenek utalva. Valószínűleg mindegyik tér- 
képdarab hordoz olyan információt a kincs helyéről, 
ami a többi darabon nincs rajta, ha nem így van, az 
adott darab egyszerűen felesleges. 

2. Elképzelhető az is, hogy egyetlen térképdarab is ad 
annyi információt, ami lehetővé teszi egy kincskereső 
expedíció elindulását, vagyis a fennmaradó lehetősé- 
gek kipróbálását idő, pénz vagy más erőforrás befekte- 
tésével. 


A fenti ,ősi" módszerrel két probléma van: egy szereplő kiesé- 
se, egy titokdarab (árnyék vagy share) elvesztése meghiúsíthat- 
ja a titok teljes rekonstrukcióját. Ha pont ez volt a cél, ez ter- 
mészetesen nem baj, de valamilyen S.O.S helyzetben sem kö- 
nyörül meg a próbálkozón. A másik probléma viszont éppen 
az, hogy a maradék titokdarabok már adhatnak annyi informá- 
ciót, amennyi a fennmaradó lehetőségeket esetleg kipróbálha- 
tóvá teszi. A titok értéke dönti el, hogy megéri-e végrehajtani a 
próbálkozásokat vagy sem. 


4 4 


$ 4 
Fat 100 


B A titokmegosztás lényege: csak több ember együtt! 





Matematikai modellek — egyenletrendszer 


A titokmegosztás matematikai módszerei mindkét problémát 
megoldják. A legismertebb módszer általánosított változata a 


Langrange-féle polinom-interpoláción alapul és nem túlságo- 
san bonyolult az elve, akár a középiskolában vagy a gimná- 
ziumban is taníthatnák. Vajon hányszor hangzott el matekórán 
az a kérdés, hogy hány pont határoz meg egyértelműen egy 
egyenest vagy egy parabolát? A módszer általánosítva ugyan, 
de ezen a kérdésen alapul. 


Első fokú polinom (egyenes) 


yza,txita, 2 pont határozza meg 
Másodfokú polinom (parabola) 
Yza,txra,tx ta, 3 pont határozza meg 


Harmadfokú polinom 
yza,tx ra txóta,txta, 4 pont határozza meg 
k-ad fokú polinom 


yza.txta. HxXr.. lta, k41 pont határozza meg 


Egy k-ad fokú polinom együtthatóit vissza tudjuk állítani, ha is- 
merjük a k-4-1 különböző helyen felvett értékét. Legyen a titok 
az x-0 helyen felvett érték, (vagyis a konstans együttható) és le- 
gyen a többi együttható véletlenül választott! Ha n részre akar- 
juk bontani a titkot, legyenek a titokdarabok a polinom x-x,, 
X2. :... Xn helyen felvett y-y,, ya, ..., ya értékei. Ha az n érték 
közül tudunk k--1 darab (x.y) értékpárost, a polinom együttha- 
tói visszaállíthatók, így a 0. együttható is, ami maga a titok. Az 
olyan sémákat, ahol az összes titokbirtokos (legyen a számuk 
n-nel jelölve) közül bármely t vissza tudja állítani a titkot, (t,n) 
küszöbsémáknak nevezzük. Ha a megadott t résztvevőnél ke- 
vesebb t, darab titokbirtokos nem tudja előállítani a titkot, va- 
lamint összes információjuk pontosan annyi, mintha nem is 
rendelkeznének titokdarabokkal, akkor a (tn) sémát egyúttal 
tökéletes sémának nevezzük. Ha a rekonstruáláshoz szükséges 
résztvevők száma pontosan annyi, mint ahány titokdarab van 
(t-n), akkor titokszétvágásról, ha kevesebb (txn), titokmegosz- 
tásról beszélünk. 


Nézzük meg egy példán, hogy mit tud nyújtani ez a módszer? 
Tegyük fel, hogy egy számkódos zár kódját szeretnénk felosz- 
tani. Meghatározhatjuk, hogy hány személy között akarjuk a 
titkot szétosztani, legyen ez mondjuk öt. Meghatározhatjuk azt 
is, hogy az öt ember közül minimálisan hány szükséges a kód 
visszaállításához. Legyen ez három, vagyis ez egy (3.5) kü- 
szöbséma í(titokmegosztás). Ekkor az öt résztvevő közül bárme- 
lyik három ki tudja nyitni a zárat, így legfeljebb két titokdarab 
elvesztése vagy megrongálódása esetén is visszaállítható a 
kód. 
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Legyen a felosztandó kód 1974. Azt akarjuk, hogy 
három ember már elő tudja állítani a kódot, ezért egy 
másodfokú egyenletet kell felírni: 


válasszuk meg az együtthatókat: 





A választott számokkal a következő egyenlet adja további 
munkánk alapját: 


Mivel öt ember között osztjuk szét a kódot, öt számpárost kell 
generálnunk szabadon választott x értékek mellé: 





Ezután minden résztvevő megkapja a maga (x,y) számpárosát 
és az eredeti együtthatókat megsemmisítjük. Ezután állítsa 
vissza a kódot mondjuk ET, E3 és E5 (többen is lehetnek, de 
elég csak hármat figyelembe venni)! Az ő számpárosuk rendre 
(12;5346), (22;13216), (19;10372). Ezekkel a következő három 
egyenlet írható fel: 


Ez pedig nem más, mint egy lineáris, háromismeretlenes 
egyenletrendszer. Három független egyenletünk van, ezért az 
egyenletrendszer megoldható, sőt minket nem is érdekel min- 
den ismeretlen, csak a,. Nem szaporítom soraim a levezetés- 
sel, de e három egyenlet megoldása pontosan a várt a,—1974 
eredményt adja! (Aki nem hiszi, számolja ki!) 


A modell tulajdonságai 


Foglaljuk össze, milyen tulajdonságokkal bír ez a módszer! 

TA Látható, hogy ha háromnál több számpáros (titokdarab) 
áll rendelkezésre, akkor is elég a számoláshoz a három 
adat. Ha viszont háromnál kevesebb számpárosunk 
van, az egyenletrendszer nem oldható meg, mert há- 
rom ismeretlenünk van és csak kettő független egyenle- 
tet tudunk felírni. Így egy vagy két titokbirtokosnak 
ugyanannyi információja van a titokról, mint egy olyan 
kívülálló embernek, akinek egyetlen számpárja sin- 
csen. Mindenkinek 10000 próbálkozása marad. Ezért a 
séma tökéletes. Bizonyítható (és első-, másodfokú poli- 
nomok esetében akár koordináta-geometriával is belát- 
ható), hogy bármely két titokdarab együttesen is nulla 
ismeretet hordoz a titokról, vagyis két titokdarab isme- 
rete esetén éppen annyi a szóba jöhető kódok száma, 
mintha nem tudnánk semmit. 

AA Ha új fél csatlakozik a csoporthoz (de a visszaállítás- 
hoz szükséges résztvevők száma nem változik), egysze- 
rűen kiszámolunk neki is egy értékpárt: A már meglévő 
titokdarabokat nem kell megváltoztatni. Mivel az ere- 
deti együtthatók megsemmisítésre kerültek, ideiglene- 
sen szükség van a titok rekonstruálására. 
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HA Ha a titokdarab-hordozók nem egyformán fontosak, a 
modell azt is tudja kezelni. Osszuk az ,árnyékok hor- 
dozóit" két csoportra, az első csoport tagjai kapjanak 
egy titokdarabot, míg a második csoporthoz tartozók 
kettőt. Ha a példabeli három titokdarab szükséges a 
visszaállításhoz, a második csoportból bármely kettő, 
az első csoportból bármely három személy visszaállít- 
hatja a titkot, illetve a harmadik lehetőség az, hogy az 
első csoportból egy és a második csoportból is egy ti- 
tokdarab-birtokosra van szükség a visszaállításhoz. (A 
lényeg, hogy a visszaállításban részt vevő tagok össze- 
sen legalább a szükséges számú titokdarabot birtokol- 
ják.) Általában igaz, hogy ha meghatározzuk azokat a 
priorizált vagy egyenrangú részhalmazokat, amelyek 
jogosultak a titok visszaállítására, készíthető olyan 
megosztási séma, amely teljesíti a feltételeket. 

AA Viszonylag egyszerű matematikai problémán és nem 
egy (még) megoldatlan problémán alapul. 

TA Ha azt akarjuk, hogy az információról a megosztásban 
résztvevők ne tudjanak semmit, szükség lehet egy meg- 
bízható harmadik félre (trusted third party), aki a számí- 
tásokat elvégzi. 


Igaz az is, hogy ha a séma tökéletes, a titokdarabok mérete el- 
méleti szempontból legalább akkora, mint maga a titok. Ha két 
titokdarab-birtokos összesen nulla információval rendelkezik a 
titokról, magának a harmadik titokdarabnak legalább annyi in- 
formációt kell hordoznia, mint maga a titok. 


Matematikai modellek — logikai műveletek 


Lehetőség van egyszerűbben kivitelezhető algoritmus megva- 
lósítására is — XOR művelet használatával. Az egyszerűség fő- 
ként egy esetleges célhardver megvalósítás miatt lehet fontos. 


1. Legyen a megosztandó információ bináris reprezentá- 
ciója S. 

2. A megbízható harmadik fél eggyel kevesebb véletlen 
bitsorozatot generál, mint ahány résztvevő van (n), de 
ezek hossza S hosszával megegyező. 


3. Legyenek ezek a bitsorozatok R,, R;, ...,R,.. 


4. Ezután kiszámolja a C-S XOR R, XOR R;... XOR R,, 
értékét és megsemmisíti S-t valamint szétosztja a felek 
között R,,R;,...,R,.1/C értékeket (mindenkinek egyet). 

5. A visszaállításhoz az 5-C XOR R.R;,...R, , értékét kell 
kiszámolni. 





Egyszerűsített XOR művelet: ha az egymás felett lévő , 1" bitek 
száma páros, az eredmény , 07, ha páratlan, az eredmény ,1". 
A modell tulajdonságai 


Foglaljuk össze, milyen tulajdonságokkal bír ez a módszer! 
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A Ha a szükséges n titokdarabnál kevesebb áll rendelke- 
zésre (a többi megsemmisült vagy elveszett), a titok 
nem állítható vissza. Éppen ezért ezt a módszert nem 
titokmegosztásnak, hanem titokszétvágásnak nevez- 
zük. A szétvágás kényes a titokdarabok meglétére, ezért 
csak indokolt esetben használjuk, ha tudomásul vettük, 
hogy a szétvágás nem tudja biztosítani a megosztás 
azon lehetőségét, hogy a titkot tárolás-biztonsági okok- 
ból is megoszthatjuk. 

mA A visszaállításhoz minden darabra szükség van, ezért 
ez egy (n,n) küszöb séma (titokszétvágás). 

A A titokdarabok mérete fizikailag is megegyezik a titok 
méretével. 

TA Ha új fél csatlakozik a csoporthoz, az csak akkor kap- 
hat titokdarabot, ha a titkot időlegesen egyesítjük és C 
értékét újraszámoljuk az új R figyelembe vételével. A 
már kiosztott R darabokon azonban nem kell változtat- 
ni, de akinél C volt, az új darabot kap. Célszerűnek lát- 
szik, hogy a titokdarabok ne legyenek egymástól meg- 
különböztetve, így viszont az sem mondható meg, 
hogy kinél van a C darab, ezért az egész szétvágási 
procedúrát elölről kell kezdeni. A polinom-alapú sémá- 
nál egyetlen már meglévő együtthatót sem kellett el- 
dobni. 

ma A visszaállításhoz pontosan annyi titokdarab szüksé- 
ges, mint amennyire szétdaraboltuk a titkot. Ez a séma 
nem tudja figyelembe venni a résztvevők eltérő fontos- 


ságát és nem viseli el hiányzásukat sem: mindenkire ; 


szükség van. 

HI Ha azt akarjuk, hogy az információról a megosztásban 
résztvevők ne tudjanak semmit, szükség van egy meg- 
bízható harmadik félre (trusted third party), aki a számí- 
tásokat elvégzi. 


Egy geometriai modell 


Merőben másként is megközelíthetjük a problémát. Legyen a 
titok reprezentációja egy pont (x,y,zZ) a háromdimenziós tér- 
ben. Legyenek a titokdarabok a pont vetületei az (x,y), (x,2), 
(y.2) tengely által meghatározott síkokra. (Ez az eredete az 
árnyék elnevezésnek?) Egy ilyen vetület az eredeti ponttal 
együtt egy egyenest határoz meg, amelyen a titoknak rajta kell 
lennie. Bármely két titokbirtokos vissza tudja állítani a titkot — 
ami az egyenesek metszéspontja —, ezért ez egy (2.3) küszöb- 
séma. 

Ez a séma tökéletes vagy sem? A kívülálló számára az egész 
térben bárhol lehet a pont, az árnyék számára azonban már 
adott egy egyenes, bár mindkettőnek végtelen sok lehetősége 
van. De tételezzük fel, hogy létezik egy olyan, a titok jellegé- 
ből meghatározható h, melyre egyszerre teljesül: 


/XIish /IYish IZIsh 


Ekkor egy kívülálló számára már csak egy tér-rész (egy kocka 
belseje) marad véges sok ponttal, egy árnyéknak pedig csak 
egy szakasz. E két ponthalmaz már jóval kézzelfoghatóbb: a kí- 
vülállónak 8h", az árnyék tulajdonosának 2h pontja van a pró- 
bálkozáshoz. Tehát ez nem tökéletes séma. (A parabolás, 
számzáras példánál is meghatározható egy h-9999, azonban 
a titokbirtokos saját darabjának a birtokában sem tudja szűkí- 
teni a szükséges próbálkozások számát: neki is 10000 kódot 
kellene kipróbálnia.) 





Jogosult és jogosulatlan résztvevők 


Sajnos az itt bemutatott módszereknek van egy közös 
problémája: visszaállításkor a titokdarabok egzakt 
módon nem ellenőrizhetők le: 

FA Ha a visszaállítás a minimálisan szükséges 
résztvevőkkel történik, egy rosszindulatú résztvevő ha- 
mis titokdarab megadásával megakadályozhatja a re- 
konstruálást, és személyét nem lehet kideríteni. 

JA Ha a minimálisnál több személy vesz részt a visszaállí- 
tásban, előfordulhat, hogy valaki csak színleli a titokda- 
rab felfedését (esetleg nincs is titokdarabja) és mégis 
megismeri a titkot. 

Viszonylag egyszerű megoldás lehet valamilyen — aláírásra al- 
kalmas — nyilvános kulcsú algoritmus kiegészítő használata. 
Ha ugyanis a megbízható harmadik fél (akit egyébként a szak- 
irodalom dealer-nek nevez) a titokda- 
rabok kiosztása előtt aláírja azokat a 
saját privát kulcsával, visszaállításkor 


Ha a megbízható pedig a résztvevők az aláírt darabot 
adják a közösbe, mindkét eset felfed- 

harmadik fél aláírja hető. Senki nem ismeri dealer titkos 
kulcsát, ezért egyik résztvevő sem 

a titokdarabokat, tudja a saját titokdarabját meghamisí- 
tani. 

a csalások egy TÉSZ2? Nem csak belülről érheti támadás a ti- 
tokmegosztást alkalmazó protokollt, 

leleplezhető. hanem kívülről is. Amennyiben a ti- 


tokdarabok felfedésének kommuniká- 

cióját illetéktelenek lehallgatják, meg- 
szerzik vagy megszerezhetik az összes titokdarabot. Ha isme- 
rik a titok rekonstruálásához szükséges algoritmust, a résztve- 
vőkkel párhuzamosan képesek előállítani titkot is. Első gondo- 
latra a titokdarabok titkosítása tűnik megoldásnak, azonban a 
titok előállítását a titkosításhoz használt kulcs hiánya meghiú- 
síthatja, így a kulcs birtokosa mindenképpen szükséges részt- 
vevővé válik. Ezért nem a titokdarabokat kell titkosítani, ha- 
nem a titokdarabok kiosztásához vagy begyűjtéséhez használt 
kommunikációs csatornát kell védeni! 


Felhasználás 


A fentebb vázolt módszereket abban az esetben használhatjuk, 
ha valamilyen információt (jelszót, mesterkulcsot vagy éppen 
jogosultságot) úgy kell megosztani a résztvevők között, hogy 
azok mindegyikének (titokszétvágás) vagy egy meghatározott 
csoportjának (titokmegosztás) jelen kell lennie az információ 
rekonstruálásakor. 

Az ilyen célú megosztás lehetőség a kulcs biztonságos tárolá- 
sára is. Ha ugyanis a részeket különböző helyeken, különbö- 
ző személyek felügyelete alatt őrizzük, nem fordulhat elő, 
hogy az információ megsemmisül. Ez titokszétvágással nem, 
csak megosztási séma használatával valósítható meg bizton- 
ságosan. 

Megoldható egy digitális aláírás jogosultságának szétosztása 
is, például egy bankban egy nagy értékű átutalást bármely két 
alkalmazott csak együttesen írhasson alá. Ez tehát a titok- 
megosztás másik felhasználási területe: egy fontos információt 
úgy bontunk fel, hogy a részek külön-külön semmire nem jók. 


Hozzáférési szintek szabályozása is megoldható az eddig be- 
mutatott eszközökkel. Vegyük a következő egyszerű példát! 
(Kérem az érdeklődő olvasókat, gondolják át a példát, mert 
sokkal egyszerűbb, mint első olvasatra tűnik!) 
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m Legyen a felhasználók besorolása Level-1, Level-2 és 
Level-3. 
m Azt kívánjuk elérni, hogy 
1. aki Level-1 jogosultsággal bír, csak a Level-1 szintű 
titokhoz férjen hozzá. 
2. aki Level-2 jogosultsággal rendelkezik, az a Level- 
1 és Level-2 szintű titok rekonstruálására egyaránt 
képes legyen. 
3. aki Level-3 jogosultságot kapott, az Level-1 , Level-2 
és Level-3 szintű információkhoz is hozzáférhessen. 





é.d 4 8 6 76 § 18 





A fenti ábrán az egyes titkokat SI, 52 és S3 pontok képviselik, 
míg a titokdarabok jelölése P1, P2, P3 és P4. A pontok megha- 
tározásának menete a következő: 

1. S1-P1 egyenesen ítetszőleges helyen) kijelölhető P2, 
amely P1-gyel együtt S1 védelmét látja el. 

2. Majd P1-P2-S2 ismeretében meghatározható egy olyan 
parabola, amely áthalad mindhárom ponton. A parabo- 
lán kijelölhető tetszőleges P3, amely P1-gyel és P2-vel 
együtt S2 titkot védi. 

3. Végül P1, P2, P3, S3 pontokkal kijelölhető egy harmad- 
fokú görbe, amin egy tetszőleges pontot kijelölve P4-et 
kapjuk. 


Ezután azok a résztvevők, akik birtokolják 
A P1 és P2 titokdarabokat, képesek S1 előállítására, 
A PI, P2 és P3 darabokat, S2 és S1 előállítására egyaránt 
képesek és végül 
JA P1, P2, P3 és P4 darabok birtokosai S3, S2 és S1 előál- 
lítására képesek. 


Mivel P1 és P2 pont mindhárom szint hozzáféréséhez szüksé- 
ges és nélkülük egyetlen titokdarab sem állítható elő, ezért ak- 
tiváló pontoknak is nevezik. 

A titokdarabok egy lehetséges elosztását és a résztvevők jo- 
gosultságait a következő táblázat szemlélteti (párokat felté- 
telezve): 


Résztvevő 1 Résztvevő 2 











Level-1: PT P2 z x x 
Level-2: Pi:B3 B z v x 
 Level-3: Pip P2, P4 v L v 





Megjegyzem, hogy a gyakorlati megoldásokban a polinomo- 
kon alapuló titokmegosztási sémákat modulo algebra berkein 
belül értelmezik, vagyis a cikk elején említett egyenlet 








igazából így néz ki: 





Az alapelv megértését ez nem befolyásolja, de amíg az első 
verziót egyenesekkel és parabolákkal lehet szemléltetni, addig 
a moduláris változatot képtelenség vizuálisan alátámasztani. 

Más megközelítésben már sokan találkozhattunk a titok- 
megosztás alkalmazásával. Gondoljunk csak a nyíltkulcsú tit- 
kosításokra! A hagyományos titkosításnál a közös titok egyez- 
tetése volt a fő probléma, amelyet ma a PKI rendszerek eszkö- 
zei hidalnak át. Azonban, ha az egyik legismertebb kulcscse- 
re protokollt, a Diffie-Hellman-t szemügyre vesszük, az sem 
tesz mást, mint a közös titkos kulcsot felbontja két részre, me- 
lyeket a kommunikáló felek kicserélnek, így képesek előállíta- 
ni egy olyan kulcsot, amit más nem ismerhet meg. Igaz, hogy 
a protokoll nem egy meghatározott titkot bont ketté, hanem 
két részből rak össze , valamit", de bizonyos nézőpontból ez 
is titokmegosztás. Hasonló elv mutatható meg a legtöbb 
nyíltkulcsos algoritmus működésében is. 


Ez a cikk ugyan elméletibb lett, mint a korábbi adatrejtéssel 
foglalkozó, de remélem sokak fejében ébresztett gondolatokat! 


Virasztó Tamás 
wacherEgwestel900.net 
http:/wacher.fpn.hu/ 


Tanúsítványkiadók 


a Vindowsban 


A Windows Server 2003, 


újdonságai 


Enterprise Edition 


Ebben a részben a CertiSrv webfelületet, a módosítható (v2) X.509 tanúsítványsablonokat és az auto- 
matikus tanúsítványkiállítást (felhasználók számára!) tekintjük át az új CA Server újdonságai közül. 


A Certificate Services webfelülete 


Mielőtt belevágnánk a Windows Server 2003 újdonságaiba, ta- 
lán érdemes belenézni a Certificate Services webes felületébe. 
Ez a felület — ha telepítve van — minden CA szolgáltatásnál 
megtalálható (bár nem feltétlenül kell, hogy ugyanazon a ki- 
szolgálón fusson, ahol a CA maga). A webes felület a tanúsít- 
ványkérés egyik eszköze (ezen kívül kérhetünk tanúsítványt 
magából a tanúsítványkezelő MMC konzolból is, illetve az al- 
kalmazások a megfelelő programozható bővítményeken ke- 
resztül). Mindezek mellett van olyan tanúsítványtípus (sablon), 
amit csak ezen a webes felületen keresztül szerezhetünk meg, 
ez pedig a Smart Card bejelentkezéshez szükséges típus. 

A Certificate Services webfelületét a http://cszervernév:/ 
certsrv/ címen érhetjük el. A bejelentkezés után (ami persze le- 
het az Internet Explorer által a háttérben elvégzett, látszólag 
automatikus is) a CA kezdőlapjára érkezünk. Itt három irányba 
indulhatunk el: 


TA Reguest a certificate — tanúsítvány kérése 

TA View the status of a pending certificate reguest — folya- 
matban lévő tanúsítványkérelem státuszának lekérde- 
zése; illetve a kiadott tanúsítvány letöltése (erre akkor 
van szükségünk ha a CA a tanúsítványt valamiért nem 
adja ki automatikusan — például mert Stand Alone CA- 
val van dolgunk, vagy az Enterprise CA megfelelő tanú- 
sítványsablonjában ezt külön beállítottuk) 

HA Download a CA certificate, certificate chain, or CRL — 
a CA saját tanúsítványának (esetleg tanúsítványláncá- 
nak) és a tanúsítvány-visszavonási listának (CRL) letöl- 
tése. A kiadott tanúsítványokba kódolt CRL illetve AIA 
mezők (lásd az előző számban) is erre a területre mu- 
tatnak 


Haladjunk tovább a tanúsítványkérés mezsgyéjén. A ,Reguest 
a certificate" feliratra kattintva (Windows 2000-en az opció ki- 
választása után az oldal alján található ,Next" gombot kell 
használnunk) újabb választási lehetőségünk van: 


TH A webes felületen megjelenik a bejelentkezett felhasz- 
náló által kérhető tanúsítványsablonok listája, ezek kö- 
zül választva (a már meglévő bejelentkezési informá- 
ciók felhasználásával) a lehető legegyszerűbben jutha- 
tunk hozzá a tanúsítványoz, vagy: 

mA választhatjuk az , Advanced Certficate Reguest" op- 
ciót, ahol elvégezhetjük a tanúsítványkérés finomhan- 
golását. 


tech.net SET WE v i 


A Microsoft Certificate Services - Microsoft Internet Explorer 
Fle  Edt View  Favortes Tools Help 
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Advanced Certificate Reguest 





The policy of the CA determines the types of certificates you can reguest, Click one 
ofthe following options to: 


(Ereate and submit a reguestto this CA] 
mit a certificate reguest by using a base-i g CMC orPKCS 410 file. 
it a renevval regyest by using a base- d PKCS 87 file 
Reguest a certificate for a smart card on behalf of another user by using the smart 
card certificate enrollment station 


Note: You must have an enrollment agent certificate to submit a reguest on behalf of another 
user. 











B A részletes tanúsítványkérés első oldala 


A felkínált három lehetőség a következő: 

HA Create and submit a reguest to this CA — Tanúsítványt 
kérünk egy webes kérdőív kitöltésével 

A Submit a certificate reguest... — PKCS §$10 vagy CMC 
formátumú fájlba mentett, előre elkészített tanúsítvány- 
kérést, vagy tanúsítvány-megújítási kérelmet küldünk a 
kiszolgálónak 

A Reguest a certificate for a smart card... — Smart Card ta- 
núsítványt kérünk egy másik felhasználó részére 


Az első lehetőséget választva végre eljutunk a részletes beállí- 
tásokig. 


A Microsoft Certificate Services - Microsoft Internet Explorer 
File Edt View  Favortes Tools Help 
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"Adáress (4) hitp:fserver2003.falatrax2003.hujcertsrvfcertrama. asp.— 


Micrasoft Certificate Semces - HET 


Advanced Certificate Reguest 





Certificate Templ 


Administrator 


Key Options: 
OCreate newkey set OUse existing key set 
CSP: [Microsoft Enhanced Cryptographic Providervt 0 v/ 
Key Usage:  - Exchange 


Key Size: [1024 ) Min ,389 





O Automatic key container name — O User specified key container name 


EJ Mark keys as exportable 
[Export keys to file 
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A , Certificate Template" mezőben kiválaszthatjuk a 
létrehozandó tanúsítvány sablonjának nevét. Ezután 
a ,Key Options" alatt a létrehozott kulcspárral kap- 
csolatosan módosíthatunk az alapértelmezett beállí- 
tásokon: 

TA Create new key set / Use existing key set — Új kulcspár 
létrehozása / meglévő kulcspár használata. Utóbbi 
esetben a Container Name mezőben meg kell adnunk 
a meglévő kulcspárt tartalmazó tároló nevét. 

JA A CSP mezőben kiválaszthatjuk a használni kívánt biz- 
tonsági modult (Cryptographic Service Provider). Ez a 
modul felelős a kulcsok tárolásáért, illetve a kriptográ- 
fiai műveletekért. Ha a kulcspárt például egy Smart 
Cardra generáljuk, itt ki kell választanunk a Smart Card 
CSP-jét. A beépített, szoftveres CSP-k a kulcspárt a fel- 
használó profiljában, titkosítva, védett helyen tárolják: 
ezek közül a legerősebb, tehát a legjobb választás a 
Microsoft Enhanced Cryptographic Provider. 

HA Ezután a kulcs felhasználásának céljáról (Key Usage), 
illetve a generálni kívánt kulcs hosszáról kell nyilatkoz- 
nunk. A példán látható, hogy az Enhanced CSP akár 16 
kilobájtos kulcsok generálására is képes. Összességé- 
ben igaz, hogy minél hosszabb egy kulcs, annál bizton- 
ságosabb, és annál hosszabb ideig tartanak a vele vég- 
zett műveletek is. 

HA A következő opcióban meghatározhatjuk, hogy a létre- 
hozott tanúsítvány melyik tárolóba kerüljön (Automatic 
vagy User specified — utóbbi esetben meg kell adnunk 
a használni kívánt tároló nevét). 

HA Mark keys as exportable - ez egy fontos opció! Ha itt 
nem állítjuk be, a kulcspár privát része nem lesz kiex- 
portálható (menthető) a rendszerből. Ez bizonyos ese- 
tekben előny (például a hardvereszközöknél), máskor 
kifejezetten hátrány (például ha a tanúsítványt hozni- 
vinni, vagy akár csak menteni szeretnénk). 

A Enable strong private key protection — ha ezt bekap- 
csoljuk, a Windows minden esetben hozzájárulásun- 
kat, sőt, ha akarjuk, még egy jelszót is kér, amikor a pri- 
vát kulcsot bárki vagy bármi használni akarja. Ha 
azonban a tanúsítványt nem a felhasználó, hanem 
mondjuk egy webkiszolgáló részére kérjük, ezt az op- 
ciót ne kapcsoljuk be (, ő" ugyanis nem tudja megadni 
a privát kulcs eléréséhez szükséges jelszót). 

TA Store certificate in the local computer certificate store — 

a másik nagyon fontos lehetőség. Ha helyi rendszer- 

gazdák vagyunk, ezt beállítva a tanúsítvány nem a fel- 

használónk, hanem a számítógépünk tanúsítványtárá- 
ba kerül. Így tudunk tehát a számítógép nevében tanú- 
sítványt kérni. 


Az , Additional Options" beállításai között a tanúsítványkérés 
egyéb beállításait találjuk. Mindenekelőtt megemlítjük az 
Additional Options" mezőt, ahova bármilyen különleges, a 
kérdőíven fel nem sorolt opciót felvehetünk (az előző számban 
ide írtuk a létrehozott tanúsítvány kiszolgálón történő fájlba 
mentéséhez szükséges bejegyzést). Emellett és ettől függetle- 
nül: ez a webes felület használható CMC vagy PKCS 810 típu- 
sú kérések összeállítására is, anélkül, hogy a kérést végül elkül- 
dené a tanúsítványkiadónak! Ehhez engedélyezzük a ,Save 
reguest to a file" opciót (ezután meg kell adnunk egy fájlnevet, 
ahova a varázsló elkészíti a kérésfájlt.). A ,Reguest Format" 
(kérés formátuma) illetve a , Hash Algorithm" (ujjlenyomat-al- 
goritmus) mezőknek is ekkor van igazán értelme. 


wWurtitigg wit Wii. t 4 W § 


Ha a kérést nem fájlba mentjük, a , Submit" gomb megnyomá- 
sára elindul a gépezet, a böngészőbe letöltődő ActiveX kom- 
ponens utasítja a kiválasztott CSP-t a kulcsgenerálásra, majd a 
létrehozott kulcsok segítségével összeállítja a tanúsítványké- 
rést, és elküldi azt a CA-nak. Ezután már csak egy feladatunk 
van: rákattintani az ,Install this Certificate" feliratra, és telepí- 
teni a létrehozott tanúsítványt (persze csak akkor, ha a kérel- 
münket a CA azonnal - és jóváhagyólag — elbírálta). 


A tanúsítványsablonok 


Mint arról már az előző részben is szó volt, az Enterprise 
üzemmódban működő Windows CA-k a tanúsítványokat előre 
gyártott sablonok alapján állítják elő. Ezeket a tanúsítványsab- 
lonokat az Active Directory-ban tárolták, Windows 2000-ben 
az Active Directory Sites and Services eszköz segítségével te- 
kinthettük meg őket. Ott a jogosultságok beállításait leszámít- 
va más módosítást nem ejthettünk rajtuk. A Windows 2003 
esetén ugyanígy az Active Directory-ban találjuk a sablonokat, 
de a kezelésükre készült egy külön eszköz (a Certificate 
Templates MMC konzol), amit például a tanúsítványkiadó 
szolgáltatás saját konzoljának (Certification Authority) 
Certificate Templates sorára jobb gombbal kattintva, majd ott a 
Manage... parancsot választva indíthatunk el. 
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E A tanúsítványsablonokat kezelő MMC modul Windows 
Server 2003 alatt 


A Windows Server 2003-ban (egészen pontosan ezek címtárá- 
ban) alapvetően két fajta tanúsítványsablont találunk: 


A az úgynevezett ,v1", azaz egyes típusú sablonokat, 
melyek továbbra is csak olvashatók, és a Windows 
2000 Server, valamint a Windows Server 2003 Stan- 
dard Edition CA-i képesek kiadni 

A valamint az úgynevezett ,v2" sablonokat, amelyek 
beállításai lényegesen széleskörűbbek, írhatók-olvas- 
hatók, viszont ilyen típusú tanúsítványokat csak a Win- 
dows Server 2003, Enterprise Edition kiszolgálón futó 
CA adhat ki. 


Az ábrán látható verziószámok (4.1, 3.1, 105.0, stb.) nem 
keverendők össze a fenti besorolással. A v1 típusú tanúsítvá- 
nyok az eszközben szürke, a v2 típusúak pedig színes ikonnal 
jelennek meg, ezen kívül jól felismerhetők a , Minimum 
supported CAs" oszlop tartalma alapján is. 

A v1 típusú tanúsítványokon továbbra is csak a jogosultságokat 
módosíthatjuk ahhoz, hogy egy felhasználó egy adott típusú ta- 
núsítványt kaphasson, a tanúsítvány sablonjára ,Read" és 
sEnroll" jogokkal kell rendelkezni. Ezen kívül, a v1-es tanúsít- 
ványsablonokat duplikálhatjuk (,Duplicate Template" pa- 





rancs), aminek hatására az eredeti tanúsítványsablonnal mege- 
gyező tartalmú v2-es tanúsítványsablon jön létre. 


A v2-es tanúsítványsablonok beállításai 


A v2-es tanúsítványsablonok beállításainak megtekintéséhez 
egy v1-es , User" típusú tanúsítványsablont duplikáltunk. A to- 
vábbiakban az így létrejött , Copy of User" tanúsítványsablon- 
nal dolgozunk. Nézzünk néhány érdekesebb opciót: 
A tanúsítványsablon beállításainak , General" oldalán a tanú- 
sítványok megújítására vonatkozó beállításokat találjuk: 
WA Validity Period: a tanúsítványok érvényessége 
HI Renewal Period: az az időszak, ameddig a tanúsítvány 
eredeti kulcsokkal megújítható 
HA Publish certificate in Active Directory: ha beállítjuk, a 
CA exit modulja a sablon alapján létrehozott tanúsítvá- 
nyokat (a tanúsítványt kérő felhasználó vagy számító- 
gép neve alá) publikálja az Active Directory-ba 
HA Do not automatically reenroll if. . .: automatikus tanúsít- 
ványkérés esetén a tanúsítványt nem adja ki újra, ha a 
tulajdonos nevén azonos típusú tanúsítvány már közzé 
van téve az Active Directory-ban. 
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Issuance Reguirements ] Superseded Templates ] Extensions l Security 
Subject Name 


Gieneral Reguest Handing ] 


Purpose: 





TT Archive subjects encryption private key 
7 Indude symmetric algorthms allowed by the subject 


FT Delete revoked or expired certificates (do not archive) 


Minimum key size: (1024 s] 

[7 Allow private key to be exported 

Do the following when the subject is enrolled and when the private key 
associated with this certificate is used: 

(6 Enroll subject without reguiring any user input 

C Prompt the user during enrollment 


c Prompt the user during enrollment and reguire user input when the 
private key is used 


To choose which eryptographic service providers CSPs. 
(CSPs) should be used, click CSPs. — 





megk [Dera] ar ] 


E A tanúsítványsablon beállításainak egy oldala 


A következő ,Reguest Handling" oldalon a tanúsítványok 
kérésével kapcsolatos további beállításokat találjuk, többek 
között: 

JA Purpose: a tanúsítvány használatának célja (alapvetően 
titkosítás, digitális aláírás és smart card logon lehet) 
Archive subjects encryption private key: a privát kulcs 


mentése (erre még visszatérünk) 


8 


HA Minimum key size: a használható minimális kulcs- 
hossz 
A Allow private key to be exported: ha töröljük, a létre- 


hozott tanúsítványok privát kulcsa nem lesz exportál- 
ható (akkor sem, ha azt a felhasználó úgy kérné) 

TA A ,Do the following..." opciók a privát kulcs használa- 
tával kapcsolatos sablonbeállításokat jelentik (lásd fen- 
tebb a tanúsítványkérésnél az ,Enable strong private 
key protection" mezőt) 


1) 


tecnnet tarkát wv i 


HA végül a , CSP" gombra kattintva kijelölhetjük, 
hogy az adott tanúsítvány milyen típusú CSP- 
k segítségével kérhető. 


A ,Subject Name" oldal a tanúsítvány tulajdonosá- 
nak adatai kitöltéséhez szükséges beállításokat tartalmazza. Itt 
is alapvetően két választási lehetőségünk van: 


TA Supply in the reguest: az adatokat a tanúsítványkérés 
folyamán mindenképpen meg kell adni (ez tipikusan az 
Offline típusú sablonokra igaz), vagy 

XA Build from this Active Directory information: szedje az 
adatokat az Active Directory-ból. 


Ha azt szeretnénk, hogy egy adott típusú tanúsítványt még az 
Enterprise CA-k se adjanak ki automatikusan, azaz mindenkép- 
pen szükség legyen a kijelölt személy jóváhagyására, a tanúsít- 
ványsablon , Issurance Reguirements" oldalán kattintsuk be a 
,CA certificate manager approval" pipát! 


eg álysázt sás i 1 
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General] ReguestHanding — ] 0 SubiectName  ] 
Issuance Reguirements ] Superseded Templates ] Extensions l Security ] 
Reguire the following for enrollment: 


TA cerüficate manager approval 
E Kötelező rendszergazdai jóváhagyás 


A tanúsítvány kérésével és kiadásával kapcsolatos biztonsági 
beállításokat természetesen továbbra is a , Security" oldalon ta- 
láljuk meg. 


Automatikus tanúsítványkérés és kiadás 


Automatikus tanúsítványkérés már a Windows 2000-ben is lé- 
tezett (a számítógépek önmaguknak kérhettek tanúsítványo- 
kat). A Windows Server 2003 lehetővé teszi, hogy a felhaszná- 
lók illetve számítógépek más v2-es típusú tanúsítványokat is 
automatikusan kérjenek a vállalati CA-tól (ennek szomorú fel- 
tétele az, hogy v2-es tanúsítvány kiadásához Windows Server 
2003, Enterprise Edition szükséges). Az automatikus tanúsít- 
ványkérés lépéseit mondjuk egy felhasználói (User) tanúsít- 
ványsablon segítségével mutatjuk be. 

Első lépésként a meglévő v1-es User sablont duplikáljuk 
(Duplicate Template parancs, a létrehozott új sablont nevez- 
zük mondjuk , Autoenrolled User"-nek!). Ezen a sablonon már 
beállítható a ,Read" és ,Enroll" mellett az , Autoenroll" jogo- 
sultság is. 
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General] ReguestHanding — ] — SubiectName 1] 


Issuance Reguírements ]/ Superseded Templates ]/ Estensions Security 


Group or user names: 













£2. Administrator (FALATRAXZOOZYádministrator) 
2 Authenticated Users 
€É2 Domain Admins (FALATRAXZDOZND omain Admins) 

€Í? Domain Users (FALATRAXZOOZND omain Users) 

€€7? Enterprise Admins (FALATRAXZOOZNEnterprise Admins) 


Add... I Remove ] 


Deny 


Permissions for Domain Users 






Full Control On a 
Read On a 
űj A a 
aj u 
a 
te KRes szlzélíeáza tat or for advanced settings, Advanced 





D6k Jeee] a ! 


E Jogosultságok egy automatikusan kérhető tanúsítvá- 
nyon 


A ,Read" jog azért nem látható az ábrán, mert azt az 
Authenticated Users jogosultságai között már definiáltuk. 

A következő feladat a tanúsítványkiadón engedélyezni az 
sAutoenrolled User" tanúsítványsablonok kiadását (emlékez- 
zünk: Certification Authority 2 Certificate Templates 2 New 
72 Certificate to lssue...) 


(Es Certification Authority 

Elle — Action  Wiew Help 

€5lölmiBB!8e 

Certification Authority (Local) 

ELÉ Falatrax 2003 Enterprise CA 
CI Revoked Certificates 
CI Issued Certificates 


CI Pending Reguests 
CI Failed Reguests 



















EDirectory Email Replication 
GadDomain Controller 
GedDomain Controller Authentication 





E Az új tanúsítványsablont vegyük fel a CA-n kiadható 
tanúsítványok listájába! 


A ,kiadás" oldallal már készen is vagyunk. Az utolsó feladat a 
kérés" beállítása: a Group Policy segítségével be kell állíta- 
nunk, hogy a tartományi felhasználók kérjenek ilyen tanúsít- 
ványt. Ehhez a megfelelő Group Policy objektumban (mondjuk 
a Default Domain Policy-ben) keressük meg a User 


Configuration 2 Windows Settings 2 Security Settings 2 
Public Key Policies 2 Autoenrollment Settings sort, és kattint- 
sunk rá kettőt! 





Mesa n dei ui 2]xi 


General ] 


Enroll user and computer certilficates automatically 





€ Donot enroll certificates automatically 
(G Enroll certificates automatically 
[7 Renew expired certificates, update pending certificates, and remove 
revoked certificates 


[7 Ájpdate certificates that use certificate templates 





ax [TETT a] 


E Az automatikus tanúsítványkérés beállításai a Group 
Policy-ben 


Ha itt kiválasztjuk az , Enroll certificates automatically" opciót, 
a házirend következő kiértékelése után a Windows az Active 
Directory-ban automatikusan utánanéz a felhasználó részére 
kérhető tanúsítványoknak és meg is kéri azokat. A ,Renew 
expired..." bekapcsolásának hatására a rendszer megpróbál- 
kozik a lejárt és folyamatban levő tanúsítványok frissítésével, 
illetve törli a visszavont tanúsítványokat. 

Ne feledjük, hogy a Group Policy a Windows XP munkaállo- 
másokon csak némi (adott esetben akár másfél órás) késlelte- 
téssel értékelődik ki, ezért ha gyorsabb hatást szeretnénk elér- 
ni, adjuk ki rajtuk a 








te /target:user /force 


parancsot. 


Ha mindent jól csináltunk, a felhasználó következő bejelentke- 
zésekor a Windows automatikusan legenerálja a megfelelő ta- 
núsítványokat. Ezt ellenőrizhetjük is, mindjárt három helyen: , 
HA a munkaállomáson felhasználó tanúsítványtárában 
A a kiszolgálón a tanúsítványkiadó szolgáltatás MMC 
konzoljában (, Issued Certificates"), illetve 
A az Active Directoryban, a felhasználó tulajdonságlap- 
jának ,Published Certificates" oldalán. 


. .. folytatjuk! 


Fülöp Miklós 
mick€netacademia.net 


AR Fermat-kistétel hétköznapi 


bizonyítása 


Avagy meddig bírja még az RSA? 


E cikk megírásához óriási lökést adott egy magyar fejlesztő, aki nem kevesebbet állít, mint hogy elké- 
szítette a világ legjobb titkosítóalgoritmusát, mely ,nem olyan nehézkes, mint az RSA, nem támaszko- 
dik az ikerprímekre, következésképp időtállóbb az RSA-nál, ami idővel úgyis törhető lesz". Ez az úri- 
ember a titkosítóalgoritmusok minimális ismerete nélkül alkotott azoknál jobbat. Nincs is biztosabb 
alap az algoritmusfejlesztében, mint a tárgyi tudástól el nem vakított éleslátás! 


Ebben a cikkben olvasmányos módon, de mégis matematikai 
módszerekkel adok választ néhány alapvető kriptográfiai kér- 
désre. Meddig bírja még az RSA? Hisz például a DES 
kipurcant, helyét — mind a szabványokban, mind a gyakorlat- 
ban - lassan elfoglalja az AES (Rijndael). Van-e elegendő prím- 
szám ahhoz, hogy a föld minden lakosának saját RSA- 
kulcspárja lehessen? 

De hogy még egy pillanatig a Magyar Feltalálónál maradjunk, 
meg kell említenem, hogy minden szava téves: a valóságban 
az RSA hiperelegáns, semmi köze az ikerprímekhez és a kulcs- 
hossz növelésének nincs semmilyen akadálya -— tehát időtálló. 
Magát az algoritmust 2001 decemberében már elmagyaráztam 
e lap hasábjain, ez a cikk azóta a Netacademia Tudástárban is 
megtalálható. Anélkül, hogy ismétlésekbe bocsátkoznék, fele- 
levenítem, hogy miből is lett a cserebogár. Ha veszünk egy tet- 
szőleges számot (x-et), és felemeljük egy olyan hatványra, ahol 
a hatványkitevő prímszám (legyen ez a szám P), majd a hatvá- 
nyozás eredményét elosztjuk P-vel, az osztás maradéka x lesz. 
Matekul: 


X mod Box 
konkrét számokkal (x-4, P-11) 
4"mod11-4 


Hát nem csodálatos? A képlet felfedezője Pierre de Fermat, kö- 
zépkori francia matematikus, a képlet neve pedig Fermat 
kistétele. Ebből a képletből indult ki Rivest, Shamir és 
Adleman, hogy megalkossák a nyílt kulcsú titkosítás legelegán- 
sabb algoritmusát, az RSA-t, ami így műkodik: 

Titkosítás: 


Text mod N-Cipher 
Kibontás: 
Cipher" mod N-Text 


konkrét számokkal (e—-91, d-3611, N-10807, titkosítandó 
"text"-44).: 
Titkosítás: 


44" mod 10807 - 1269 
Kibontás: 


1269" mod 10807 — 44 
Így működik. Ez mind szép és jó, de anno függőben hagytuk, 





hogy vajon miért, és főleg: meddig? Először a miértre adom 
meg a választ. 


A Fermat-kistétel bizonyítása 


A matematika (kártya?Nára bizonyított tételeket használ építő- 
kockaként. Itt nincs helye a pusztán kísérletileg igazolható ál- 
lításoknak, tekintettel arra, hogy a végtelennel állunk szemben, 
így a kísérletezgetés (brute force) csupán szánalmas töredékét 
járhatja be a lehetséges eseteknek. Vaslogikával kell belátnunk 
az xSP mod P-x egyenlet igazságát ahhoz, hogy biztosak le- 
hessünk benne: a képlet azokon a számokon is helyesen mű- 
ködik majd, amelyek kipróbálására nincs esélyünk, számítási 
kapacitásunk, időnk stb. 

A bizonyításokban azt a részt szeretem legkevésbé, amikor a 
matematikus egy kreatív csellel rántja ki levezetését a remény- 
telen zsákutcákból. Egyesek szerint kreatív dolog egy egyenlet 
mindkét oldalát ad-hoc módon négyzetre, vagy köbre emelni - 
szerintem inkább buggyant elmére vall. Az ilyen elmével ren- 
delkező egyént matematikusnak nevezzük, s az a dolga, hogy 
amit csak lehet, bebizonyítson. Ha nem sikerül a hipotézist, 
akkor legalább az ellenkezőjét. 

A XX. század egyik legnagyobb, s egyben magyar matematiku- 
sa, a világpolgár Erdős Pál egy ízben azzal , dicsekedett", hogy 
nem kevesebb, mint 35 különféle bizonyítást tud fejből a Fer- 
mat-kistételre. Ezek zöme buggyant elme nélkül nem érthető, 
de az itt bemutatott változatot negyedikes fiam is megértette. 
Azért persze ez is tartalmaz egy hibbant, semmiből sem követ- 
kező lépést, ráadásul mindjárt az elején. A fenti képlet 
örökérvényű bizonyságához ugyanis nem a képletből indulunk 
ki, hanem... 


Az első buggyant lépés 


írjuk fel egymás után szépen sorjában az alábbi sorozat ele- 
meit! 

ÜRESSÉG E EG JESSE SES Z S TEEE] 
ahol P a cikk legelső képletében a kitevőben szereplő prím- 
szám. Számpéldával élve (brute force, de csak a gyengébbek 
kedvéért) x-4 és P-7 esetén: 


TER 1 


TA TZSAEZEA TÁSA MTESZ 


Vajon mit akarunk ezzel? Talán a szorzások eredményére va- 
gyunk kíváncsiak? Á, dehogy! Inkább azok maradékára P-vel 
való osztás esetén. Sőt, még azokra sem, csak a jellegzetessé- 
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" Avagy meddig bírja még az RSA? / Biztonsá g 


A Fermat-kistétel hétköznapi bizonyítása 
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geikre. Hogy vizualizáljam, mi érdekel minket, először felve- 
szem egy általános iskolai számegyenesre x szorzatait: 


ahhoz, hogy e sorozat P-vel vett maradékait megvizsgálhassuk, 
a számegyenes alá felvettem P többszöröseit is: 


Az első pillantásra látszik, hogy a két sorozat 28-nál találkozik 
először (ott nulla a P-vel vett maradék). Ezt a számot x és P Leg- 
kisebb Közös Többszörösének (LKT) hívjuk. Konyhanyelven te- 
hát az LKT az a szám, ahol x és P először "találkozik" végtelen 
felé történő futása során. (Ennél kisebb számoknál by definition 
nincs "randevú", mert a Legkisebb Közös Többszörösnél nincs 
Még Annál Is Kisebb Közös Többszörös, azaz MAIKKT :) ) Most 
vizsgáljuk meg x többszöröseinek maradékát! (A számegyenes 
felett nyilakkal jelöltem.) 


Mit tudunk mondani általánosan ezekről a maradékokról? 
Meglepő módon azt, hogy nincs köztük két egyenlő! Honnan 
lehet ezt tudni a nyilacskák lemérése (brute force!) nélkül? 
Most jön a vaslogika: ha lenne két azonos maradékot adó x- 
szorzatunk (az alábbi ábrán A és B a két szám, míg a két azo- 
nos méretű nyíl a két azonos maradék), e két pont közt a távol- 
ság osztható lenne P-vel. Miért? Mert az azonos maradékot 
adó számok egy ugyanolyan léptékű, de elcsúsztatott , vonal- 
zón" vannak. (Képzeljünk el egymás mellett, de picit elcsúsz- 
tatva két műanyag vonalzót. Csak abban az esetben lehet 
ugyanannyi az elcsúszás minden pontban, ha ez két azonos 
léptékű vonalzó!) 





Ha viszont az A - B távolság osztható P-vel is (és x-szel is, hisz 
az x-szorzótábla adta ki az A és B pontokat), akkor az eddig 
LKT-nek tekintett számnál mégiscsak van kisebb, amin x és P 
randizni" tud. Erre csak két magyarázat lehetséges: 

A vagy az előbb mégsem jól állapítottuk meg meg x és P 
Legkisebb Közös Többszörösét (nonszensz, nem va- 
gyunk annyira ügyetlenek, hogy ne tudnánk kiszá- 
molni) 

HA vagy mégsincs azonos maradékot adó két elem az x- 
szorzatok sorozatában 

Az utóbbi következtetés a helyes. 


A második buggyant lépés 


Mit kezdjünk gyönyörű, x-szorzatokból álló sorozatunkkal? Írjuk 
egymás alá az összeset, és írjuk mellé a P-vel vett maradékukat! 


t 





Az első és utolsó sorban biztosra mehetünk a maradék értéké- 


nek megállapításánál, de 2x-től felfelé (a kérdőjelek helyén) ér- 
zünk ,némi" bizonytalanságot: fogalmunk sincs a konkrét ér- 
tékekről. Viszont az első buggyant lépésben kiderítettük, hogy 
nincs közöttük két egyforma. Ez azt jelenti, hogy ismeretlen 
sorrendben ugyan, de szépen rendre felveszik az 1,2,3,4, ... P-1 
értékeket! 

Mire megyünk ezzel? Arra, hogy az egymás alá írt egyenle- 
teinkkel számolni tudunk, például össze tudjuk szorozni az 
összes baloldalt, és az összes jobboldalt is (gondosan kihagyva 
az utolsó tagot, hogy nehogy nullával is végigszorozzuk az 
egészet), ami után a következő egyenlethez jutunk: 


Az egyenlet jobb oldalán valójában (P-1)! (olv: pémínuszegy 
faktoriális) áll, és ha jobban megvizsgáljuk, x kiemelésével a 
baloldalon is felfedezhetjük ugyanezt: 


Egyszerűsítsünk (P-1)!-gyel, az annyi mint: 





g.e.d. 

Ezzel minden (prím)számra, legyen az tetszőlegesen nagy, be- 
bizonyítottuk a Fermat-kistétel teljesülését. Már csak az a kér- 
dés, van-e elegendő prímszám a hatalmas számok körében, 
vagy a végtelen felé menetelve elfogynak? 


Végtelen sok prímszám van? 


Tételezzük fel, hogy van egy leges-leges-legnagyobb prímszám 
a világon (ha lenne ilyen, nagybaj lenne!), nevezzük ezt P-nek. 
Most számítsuk ki P, és a nála kisebb összes szám szorzatát: 


majd adjunk ehhez a szorzathoz egyet, ez lesz 0 


Vizsgáljuk meg O-t oszthatósági szempontból! Osztható-e 2- 
vel? Sajnos nem, mert a 4-1 miatt 1 lesz a maradék. Osztható 
3-mal? Nem. Ismét 1 a maradék. 4-gyel? Nem. Satöbbivel? 
Nem, nem, nem! Mindig egy a maradék! 

Tehát O vagy prímszám (ergo nem P a legnagyobb prím), vagy 
ha nem is prím, de P-ig bezárólag nem osztható semmivel, te- 
hát szorzótényezői közt egy P-nél nagyobb prímszámnak kell 
szerepelni (tehát nem P a legnagyobb prím). 

Ez a bizonyítás 2500 éves, Euklidésztől származik. Nincs új a 
nap alatt. 


Fóti Marcell 

marcellfőonetacademia.net 
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Miután az Exchange szerver telepítése véget ér — azaz a kék csík eléri a 100 99-ot —, 

ne gondoljuk, hogy készen vagyunk. Az igazi munka csak itt kezdődik. Ezután dől el, hogy a frissen 
elkészült szerverünk pár napon belül esetleg megjelenik majd egy open-relay tiltólistán vagy egy ,iga- 
zibb" vírus rövid idő alatt teljesen átveszi tőlünk a hatalmat! 


Az első és legfontosabb a megfelelő Service Packek, illetve biz- 
tonsági frissítések megléte, mind az operációs rendszer, mind 
az Exchange szerver software esetében. Ezeket mindenki in- 
gyen letöltheti, illetve a windowsupdate weboldalon elérheti, 
ezért nem térek ki rájuk részletesen. Természetesen egy-egy 
frissítés néha gondot is okozhat, túlzott paranoiás mivolta miatt 
esetleg olyasmit is letilthat, amire szükség lehet, ezért mindig 
olvassuk el a leírásokat, részletes ismertetőket, hogy nehogy 
rosszabb legyen, mint volt a , javítás" előtt. 

A munkaállomások által használt hozzáférési protokollok 
mindegyikének megvan az SSL-lel (vagy MAPI esetén IPSec- 
kel) biztosított változata is, ezért ahol lehet, állítsuk be ezt és 
tegyük kötelezővé a használatát! A védelmi eszközök követke- 
ző csoportja a víruskereső rendszerek igen széles skálája, ahol 
nem könnyű a választás. Adok néhány támpontot, amelyek 
megkönnyítik a döntést. Egy jó Exchange-vírusvédelmi rend- 
szer támogatja a VS API alapú illesztést az Exchange-hez, illet- 
ve kiterjesztés alapján képes attachment-blokkolásra (ennek 
fontosságára később még visszatérek.) 

Ezenkívül folyamatos — lehetőleg ingyenes — frissítés legyen 
elérhető hozzá a neten. Több termék ugyanis ott hasal el, hogy 
a folyamatos frissítésen próbálnak meg túl sokat keresni a gyár- 
tók, vagy nagyon macerás maga a frissítés folyamata. A leg- 
rosszabb az, amikor a frissítésre időkorlát van beállítva. Ezen 
az időn belül muszáj frissíteni (pénzért), mert ha nem tesszük 
meg, a termék ,büntetésből" leáll (!!!). Nem említek neveket, 
egy kis netes böngészéssel mindenki megtalálja a megfelelőt. 
A védelmi eszközök harmadik csoportja az SMTP/MIME scan- 
nerek, illetve tartalomszűrők. Ezeket érdemes az Exchange 
szervertől elválasztani, külön vasra tenni az Exchange szerver 
elé. Trükkös megoldás — abban az esetben, ha nincs szükség a 
speciális Exchange SMTP parancsokra a külső hálózaton (lásd 
EHLO a HELO helyett, stb.) — ha egy ilyen SMTP scannert te- 
szünk ki a netre és erre mutat a domain MX rekordja, azaz ő 
tartja oda az arcát mindenféle — a net felől érkező — mail forga- 
lomnak. Csak ellenőrzés után adja tovább a leveleket a belső 
hálózatban található Exchange szervernek. Természetesen van- 
nak beépített szűrési lehetőségek az Exchange szerverben is, 
ennek hátrányairól és buktatóiról később szólok még. Van köz- 
tük egy igen-igen kellemetlen... 


Az Outlook WEB-Access védelme 


Ha úgy döntünk, hogy szükség van az Exchange egyik leghasz- 
nosabb szolgáltatására (a 2000-es Exchange web-access felüle- 
te SP3 után már egészen kiforrott), az első lépés az SSL HTTPS 
hozzáférés megkövetelése legyen. Előtte azonban az alatta fu- 
tó IIS 5-öt is kicsit kézbe kell venni, hogy megfeleljen napjaink 
biztonsági előírásainak. Erre az egyik legjobb eszköz az 
[iislockdown] címen elérhető IIS Lockdown Tool, aminek egy- 


re frissebb és kényelmesebben telepíthető verziói jelennek 
meg. Az újabbak már megkérdezik a telepítés folyamán, hogy 
a szabályozásra váró webszervernek mi a pontos feladatköre, 
és ezek között megtaláljuk az Exchange Web-Access kiszolgá- 
lót is. Az IIS Lockdown telepítése előtt gondoljuk végig, hogy 
mire használjuk még az IIS-t, mert ennek megfelelően kell , be- 
zárni" a tool segítségével. 

Ez például egy SBS szerver esetében elég nehéz feladat, hiszen 
annak IIS-szervere sok minden másra is használatos még. Saj- 
nos pont ebben az IIS Lockdown Tool-ban bújik meg egy igen- 
csak veszedelmes akna, ami az IFS-t megvalósító M: drive-val 
kapcsolatos. Ez az M: drive minden Exchange 2000 szerveren 
alapból megtalálható, elérhetőek benne a mailbox-ok, illetve a 
public folderek. És itt a lényeg, a public folderek (PF) is látsza- 
nak, és fájlszinten kezelhetőek. Az IIS Lockdown Tool futás 
közben az összes elérhető drive-ot megnézi és a választott biz- 
tonsági szintnek megfelelően javítja, illetve átszabja a jogosult- 
ságokat is. Ebben az esetben ha a PF jogosultságokat eredetileg 
MAPI kliens alól kezeltük (Outlookból), illetve ilyen formában 
vannak beállítva, igencsak komoly káosz alakul majd ki, amint 
fájlszintű ACL-re (Access Control List-re) cserélődnek ki a jogo- 
sultsági beállítások. Ennek az lesz az eredménye, hogy egy- 
részt a régi jogosultság szerint újra be kell állítani minden 
foldert, (úgy, ahogy volt), különben nem lehet , belelátni", más- 
részt többet soha nem lesznek kezelhetőek a PF jogok MAPI 
kliensből. Több száz foldert tartalmazó struktúrában igen el- 
szomorító feladat a jogosultságok visszacsinálása. 

Ne felejtsük el, hogy az 5.5-ös Exchange-ről upgradelt rend- 
szerekben alapból MAPI-alapú jogosultságlista (ACL) található, 
ami upgrade után is olyan marad — természetesen csak az első 
nem-MAPI jogosultság-módosításig. Akkor ugyanis megválto- 
zik, és a folyamat irreverzibilis. 

Mindenekelőtt tehát állítsuk le az Exchange service-ket, 
dismountoljuk az adatbázisokat, ami magával hozza, hogy az 
M: drive nem lesz elérhető, így a Lockdown Tool sem fog kárt 
tenni benne, illetve azon keresztül a PF ACL-ekben sem. A leg- 
jobb, ha a régi öreg DOS-os SUBST parancs segítségével ki is 
vesszük az M: drive-ot az akció idejére! 

Van még egy apróság a Tool beállításaival kapcsolatban, ami 
a vele együtt települő URLScan nevű komponens finomhan- 
golását igényli. Ez ugyanis haragszik az egymás után két pon- 
tot tartalmazó stringekre (is). Az Outlook Web Access a levél 
URL-jét így képzi: subject -- .eml. Itt aztán rögtön teljesül is az 
egymás utáni két pont esete, hogyha a subject sor eleve pon- 
tot tartalmazott a végén. Például: legyen a subject , Eredeti 
uzenet." Ezek után a hivakozás így néz ki: , Eredeti 
uzenet..eml". De sokan használnak három pontot a subject 
sor végén, amiből aztán ez lesz: kaosz....eml. Ez aztán a hal- 
mozódás! Ekkor a page not found üzenetet kapja a felhaszná- 
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ló, amit az URLScan egyik INI file-jának szerkeszté- 
sével védhetünk ki. 

Erről és egyéb beállításairól az MS KB következő szá- 
mú cikke értekezik: 0309508. Illetve az Exchange 
security-ről az [exsec] címről letölthető dokumen- 
tumban olvashatunk bővebben. 





Beépített szűrők 


Az Exchange szerver beépített szűrési lehetőségekkel rendelke- 
zik, amikben sajnos egy eddig hivatalosan nem publikált hiba 
található. Ez a hiba az általam tesztelt összes (angol verziójú) 
Exchange 2000 szerver esetében fennállt, még egy SBS 2000- 
en is! Jogosan gondolhatjuk fontosnak az üres feladóval (blank 
sender) érkező levelek szűrését, hiszen ha nincs feladó, min- 
den valószínűség szerint a levél nem fontos, illetve az esetek 
többségében ez még valami vírustevékenységre is utal. Bekap- 
csoljuk tehát ezt a szűrőt, és engedélyezzük az SMTP virtual 
server egyik nagyon mélyen eldugott adatlapján az apply filter 
opciót és boldogan hisszük, hogy minden rendben van. De saj- 
nos nem így van! 


- Telepítés utáni azonnali tennivalók / Exchan ge 


E Filter messages with blank sender (!!!) 


Az említett szűrőfeltétel bekapcsolása után a fejlécben esetle- 
gesen előforduló high-bit karakterek (az összes magyar ékeze- 
tes betű például) úgy megzavarják ezt a szűrőt, hogy innentől 
az összes ilyet tartalmazó levelet kiszűri majd, és kereshetjük, 
hogy hova lett és miért. A hiba ugyanis eléggé furcsa. Ha 
ugyanis a levelezőpartnerünket John Snownak hívják, és a cí- 
me jsnowGpeldanetwork.com, a from mezőben a display ne- 
vét és a címét mutatva megkapjuk a levelet. De ha az illető ne- 
ve Ágostoni József és a címe jagostoniGohunnetwork.hu, be- 
kapcsolt szűrő esetén kereshetjük a levelét, az a filtered könyv- 
tárban lesz meg és ott is csak akkor, ha bekapcsoltuk a 
filterezett üzenetek archiválása opciót. Márpedig ez minden, 
csak nem blank sender! Vegyük észre, hogy csak a display-név 
tartalmaz ékezetes betűket, az e-mail cím természetesen nem, 
és mégis problémát okoz ez a filternek! Figyeljünk tehát oda, 
hogy milyen szűréseket használunk az Exchange szerveren, 
mert könnyen több gondot okozhatunk, mint előtte volt. 
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Szűrésre sokkal alkalmasabb eszközök a már említett 
SMTP/MIME scannerek, amiknek aztán igen sokrétű beállítási 
lehetőségei jóval biztosabban kezelhető környezetet adnak a 
rendszergazda kezébe. Egy a cikk elején említett megoldás 
szerint ha egy ilyen SMTP/MIME scannert teszünk meg a 
domain MX rekordjának, a vírusvédelmet, a tartalomszűrést és 
a küldőalapú blokkolást, illetve egyéb szűrési feltételeket még 
az Exchange szerver előtt megvizsgálhatjuk, a hibás leveleket 
kezelhetjük. Ez igen kényelmes megoldás, és az Exchange 
szerver erős védelmét nyújtja, hiszen el sem jutnak hozzá a ká- 
ros tartalmú küldemények. 

Egy ilyen külső szűrővel megoldható a feladómentes levelek 
kiszűrése is úgy, hogy a high-bites fejlécű levelek azért megér- 
keznek. Ezek a scannerek többnyire egy SPAM-detectorral is 
össze vannak építve, amik szintén jobban kézben tarthatók, 
mintha csak az Exchange-et használnánk önmagában. Termé- 
szetesen ez csak ajánlás, nem szabály. Egy jól konfigurált 
Exchange szerver önállóan is meg tudja védeni önmagát és fel- 
használóit. Ezek a programok plusz kiadást, és plusz munkát 
jelentenek, de használatukon — a fentebb említett okok és tu- 
lajdonságok miatt — érdemes elgondolkodni! 


Víruskeresők 


Mint azt már említettem, az egyik legfontosabb és leghaszno- 
sabb tulajdonság az attachment-blokkolási képesség. Ennek 
használatával ugyanis nem lesz túl nagy probléma az sem, ha 
nem tudjuk követni a heti gyakorisággal megjelenő írissítése- 
ket, vagy esetleg elfelejtjük idejében feltenni őket. Történik 
mindez azért, mert a gyanús kiterjesztéseket, mint például a 
.MBS .PIF .EXE .SYS .SCR .CMD .COM .REG stb. eleve kitiltjuk. 
Így nem áll fenn az a veszély, hogy egy esetlegesen nem túl 
friss vírusinfo adatbázis nem veszi észre a rosszindulatú kódot, 
és beengedi az adott vírust a rendszerbe. Mert azt ugye belát- 
juk, hogy a fent említett kiterjesztésű fájlok küldése a szokvá- 
nyos levelezési szokásokhoz nem valami szorosan kapcsoló- 
dik, ezért alapból kitilthatók. Ha pedig mégis ilyen fájlok kül- 
désére van szükség, tessék bezippelni előtte, így már nem le- 
het véletlenül végrehajtani! 

A másik hasznos dolog, a VS API felület, kifejezetten azért ké- 
szült, hogy a víruskereső motorok számára egységes felületen 
keresztül legyen elérhető az Exchange, így az ezt támogató ví- 
ruskeresők a leghatékonyabbak. Tudniuk kell a blokkólt 
attachmenteket karantéba gyűjteni, ahonnan visszanyerhetők, 
ha mégis szükség lenne valamelyikre. 


Mindezekből leszűrhető, hogy egy friss Exchange szerver elké- 
szülte után még sok tennivaló akad, mielőtt munkába állítjuk 
és átadjuk a lelkes felhasználóknak, vagy kitesszük az 
Internetre. Gondolkozzanak el rajta! 


Füzesi Szabolcs 
fuzesiszgosi.hu 
MCSA 
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failbox Manager 


Email-takarító gép az Exchange 


Serverben 


A 


Bár az elektronikus levelek hosszútávú megőrzése általában több mint célszerű, mégis érdemes 
megismerkedni az Exchange Server automatikus levéltörlési szolgáltatásával, a Mailbox Managerrel, 
mert bizony nem minden dolgozó levelezése érdemes a megőrzésre, s nem csak levelek pusztíthatják 
az értékes tárolási kapacitásainkat, hanem elavult naptárbejegyzések, a Deleted Items többezer törlésre 


váró eleme stb. 


A Mailbox Manager az Exchange 2000 egyik javítócsomagjá- 
ban bukkant fel a felhasználói felületen (ezt megelőzően is lé- 
tezett, csak nem volt grafikus felülete), emiatt nem túl sokan 
tudnak róla, hisz sem a korábbi dokumentációkban, könyvek- 
ben, sem a hivatalos tananyagban nincs szó róla. Ettől még lé- 
tezik! 

A Mailbox Manager szolgáltatást házirenddel (policy) vezérel- 
jük. Bizonyos szempontból a Recipient Policy testvérének te- 
kinthető: ugyanott, és ugyanúgy kell létrehozni, LDAP-filterrel 
kell meghatározni az érintett felhasználók körét stb. 

Az alábbi ábrán látható, hol kell keresnünk a Mailbox Manager 
Policyt. (Ugyanitt találják a Titaniumra áttért bátor vállalkozók 
is ezt a lehetőséget.) 
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E Mailbox Manager házirend létrehozása 





Hozzunk is létre egy olyan házirendet, melynek feladata az 
lesz, hogy az LDAP-lekérdezés által érintett levelesládákról je- 
lentést készít a 30 napnál régebbi naptárbejegyzésekről. Ter- 
mészetesen törölhetne is, így nem megalapozatlan, hogy már 
tesztelési korszakában ezt a nevet viseli: Naptártakarító. 

Az alábbi ábrán a Mailbox Manager Policy beköszönő ablakát 
láthatjuk, itt kell megadni a nevet és ide kerül az LDAP-filter, 
amiről már annyiszor írtam, hogy ezalkalommal meg sem em- 
lítem. (Ugyanezen lapszámban az Elmentett Lekérdezéseknél 
szintén LDAP-szűrőkkel dolgozunk.) Az itt látható — kellőkép- 
pen összetett — szűrő egyébként az Exchange System 
Administrator által gyárilag felajánlott minta, amit természete- 
sen saját igényeink szerint átalakíthatunk. 

(Ha nem tesszük, szűrőnk az összes felhasználót, csoportot, 
kontaktot és nyilvános mappát lefedi — más kérdés, hogy egy 
csoportobjektumhoz nem tartozik levelesláda.) 
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Naptártakarító Properties 71 xi 


General ] Maibox Manager Settings (Policy) ] Detait ] 


Name: 
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Filter rules: 
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A Mailbox Manager Policy LDAP-szűrő alapján 
dolgozik 


Mint azt bizonyára minden Exchange-rendszergazda tudja, egy 
Exchange levelesláda közel tucatnyi mappát tartalmaz, s ezek 
számát a felhasználók saját mappái még tovább bővítik. Azt 
várjuk el a Mailbox Managertől, hogy szinte műtéti pontosság- 
gal legyünk képesek kimetszeni azokat az adatokat, amelyekre 
nincs szükségünk. És valóban. Nemcsak a Maibox egyes gyári 
mappáira tudunk beállítani kezelési feltételeket, hanem a fel- 
használók által létrehozottakra is, igaz, ehhez meg kell tud- 
nunk a mappák nevét — ami nem könnyű feladat. 

A kiválasztott mappákon azután kétféle tartalomszűrés is vé- 
gezhető: egyfelől a levelek kora, másfelől azok mérete alapján 
(maximális kor, illetve maximális méret). 

A szabály által feleslegesnek ítélt tartalommal azután többféle 
módon is elbánhatunk. Egyfelől jelentést küldhetünk róla a - 
későbbiekben beállított — rendszergazdának, ez a , Generate 
report only". Mindenképpen ezt választanám kényes leveleslá- 
dák esetén (vezérigazgató stb.), illetve a házirend hatásának 
tesztelésekor. Azután lehetőség van arra is, hogy a kukába 
(Deleted Items) potyogjanak a nemkívánatos elemek, ennek 
nagy előnye, hogy ha véletlenül mégis fontos elemet távolítot- 
tunk el, a felhasználó önkezével képes véget vetni ennek az ál- 
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datlan állapotnak: visszahúzza a kukából és kész. 

Ezzel a lehetőséggel élve egyébként kétfázisú törlést 
is csinálhatunk: például az első policy kukába teszi a 
30 napnál régebbi elemeket, míg egy második házi- 
rend azonnali törlést végez a Deleted Items mappán 
a 60 napnál régebbi hulladékra. Sajnos egyetlen házirenddel 
nem lehet megvalósítani a kétfokozatú törlést, mert egy házi- 
rend, legyen bármilyen finoman hangolható is — csak egyetlen 
művelet elvégzésére képes. Vagy jelent, vagy töröl ízlés szerint 
— de egyszerre csak az egyiket. 
Nem csigázom tovább Önöket, az alábbi ábrán jól látható, mi 
mindent tud a Mailbox Manager. 


DEjeue tátááeaisi 


General . Malbox Manager Settings (Policy) ] Detais ] 


When processing a mailbox: 


] Generate report only Ka ] 


Generate report only 
Move to Deleted Items folder 


Move to System Cleanup folders 
Delete Inmediatel 





CT Inboz 30 1024 

Id Sent ltems 30 1024 

Calendar 30 Any 

OTasks 30 1024 

CT Joumal 30 1024 

[O Contacts 30 1024 

Notes 30 1024 

I Deleted Items ő 1024 

a si e Folders 1024 s] 


I sal Bemove I 


TT Send notification mail to user aíter processing 
T Exclude specific message classes: 


Message. I 
Customize, I 





Ed Mi történjen a tartalommal? Kidobjuk? 


Naptártörlőnk tehát a Calendar mappában lévő, 30 napnál ré- 
gebbi elemekről jelentést fog küldeni a rendszergazdának. Ha 
törölne is, érdemes lenne a felhasználót is értesíteni arról, ho- 
vá lettek a dolgai. Erre a célra szolgál a ,Send notification to 
user..." pipa. A kiküldendő üzenet gyárilag úgy fest, ahogy az 
a következő ábrán is látható, de teljesen átírhatjuk. Én minden- 
képpen javasolnám, hogy legalább a keretszöveg magyarul 
szóljon a felhasználóhoz, akinek elég sokkot fog okozni régi 
kincseinek eltűnése is. Ne fokozzuk ezt egy idegen nyelvű üze- 
nettel! A levél aljára pedig a ,forduljon a rendszergazdához" 
helyett tessenek valami kézzelfogható segítségforrást írni (pl. 
telefonszám). Saját tapasztalatból mondom: nagy lesz a pánik! 
Jártak már úgy, hogy leparkoltak az autójukkal valahol, majd 
mozi után nem volt ott a kocsi? Ilyen érzés fogja hatalmába ke- 
ríteni a felhasználókat. De ez már nem informatikai kérdés. 








Notification Message 2] 


JIop of message: 





The Microsoft Exchange Server Mailbox Manager has performed an automated 


eleanup of your mailbox. 


a of message: 


For addítional information contact your Exchange Administrator. 











[Eeear] [tsz] 


E A Mailbox Manager levélben értesíti a felhasználót 
ténykedéséről 





Ez a levél úgy épül fel, hogy az általunk megadható fejléc és 
lábrész között felsorolja, hogy mi mindent csinált, hány üze- 
nettel akadt dolga. 


Kizárásos alapon... 


Egy gondolat erejéig még ugorjunk vissza a korábbi ábrára, 
ahol egy olyan jelölőnégyzetet is találunk, hogy , Exclude 
specific..." 

Ez nem más, mint a szike. Itt lehet megadni sebészi pontosság- 
gal, mit is szeretnénk kimetszeni a mappákból. Tulajdonkép- 
pen egy újabb szűrő, mellyel tartalom, vagy méginkább: be- 
jegyzéstípus szerint kivételt tudunk tenni a házirend működé- 
se alól. Nyomjuk meg a Customize gombot! 


Message Classes Kia Ed 


Specify the list of messaging classes to exclude 


Exclude Message Classes: 


pe 








E Elemtípusonkénti kivételképzés a házirendben 


Soroljuk fel, mit nem szeretnénk törölni. Könnyítésképpen fel- 
vettem egy mintát, ami miatt kivételes bánásmódban részesül 
minden névjegybejegyzés, és minden olyan űrlappal létreho- 
zott objektum is, amit a névjegy-űrlap testreszabott változatá- 


val készítettek. A könnyebb indulás kedvéért íme néhány to- 
vábbi elemtípus ,neve": 

HA Naptárbejegyzés: IPM.Appointment 

HA Feladat: IPM.Task 

HA Névjegy: IPM.Contact 

TA Feljegyzés (sárga cetli): IPM.Note és IPM.StickyNote 


(Ez utóbbi kettő közül random módon válasszunk, mert tőlem 
nem tudják meg, mi a különbség köztük! Használ valaki elekt- 
ronikus sárga cetlit ebben az országban?) 


És már indulhat is! 


Miért? Hát nem fut? Nem bizony! Ehhez előbb a kiszolgáló tu- 
lajdonságlapján be kell állítanunk, mikor, milyen időközön- 
ként szeretnénk dolgoztatni ezt a házirendet. (Alapértelmezés- 
ben soha.) 

(Nem kell ezen a plusz lépésen meglepődni, az Exchange 
System Manager tele van ilyenekkel. Hogyan működnek pél- 
dául a spamfilterek? Első lépésben fOrganization szinten] fel- 
soroljuk a veszélyes domaineket, majd ahhoz, hogy működjön 
is, az SMTP Virtual Serveren, az IP-címnél (!) még el kell gon- 
dosan helyezni egy pipát...) 

[B Allciobal address lists 1 

E CI offline Address Lists 
E1-CI Recipient Update Serv. 
B a Detais Templates 

a Address Templates 


2] Administrative Groups 
6 I First Administrative Gr 






Directory Access ] Polcies ] Security ] Monitoring ]  FulrText indesing 
General ] Locales . Maibox Management ] Diagnostics Logging ] Detats 


Start mailbox management processz 


ÉLÉB savas kae 
§ sz Neveram Customíze... 
6. BH PLATAN "Beporting: 
B  Routing Groups IN ül 
E.G Chat Communities (Send summary report to administralór 
FA ég] Folders Send detal report to administrator 
83 Tools 1 
Marcel Foti Momo. ] 


E3 A Mailbox Manager Agent paraméterezése 


A Mailbox Manager futását a szokásos módon lehet időzíteni, 
nem is vesztegetek rá több szót. Ennél fontosabb ugyanis a je- 


EZ NEM INFORMATIKA! 
EZ EGY SZEMÉTDOMB! ! 
EGY ÁTKOZOTT KUPLERÁJ!!! 


MI TÖRTÉNT? 








lentésküldési lehetőség, ami lehet részletes és össze- 
sített. A részletes a következő információkat tartal- 
mazza: mely levelesládákat dolgozta fel, abban hány 
üzenet felelt meg a szűrési feltételnek és azokkal mit 
csinált, s ez összességében mekkora helyet szabadi- 
tott fel. Egy dologról ne feledkezzünk meg: adjuk meg a rend- 
szergazda postafiókját! 


Summary Report 
A summary report így néz ki (minta): 


The Microsoft Exchange Server Mailbox 
Manager has completed processing mailboxes 
Started at: 11/26/03 12:55:03 

Completed at: 11/26/03 12:56:08 

Mailboxes processed: 243 
Messages moved: 53 

Size of moved messages: 
Deleted messages: 42 
Size of deleted messages: 


12.65 KB 


45.30 KB 


System Cleanup Folders 


Emlékezzünk még meg a műveletek (törlés, értesítés) közt fel- 
sorolt , Move to System Cleanup Folders" lehetőségről. Ha ezt 
választjuk, minden ,törölt" elem a levelesládában marad, 
amelynek gyökerében létrejön ez a bizonyos System Cleanup 
Folders mappa, benne pedig kialakul az eredeti mappahierar- 
chiát követő könyvtárszerkezet. Ez a lehetőség tehát az egysí- 
kú , Deleted Items" utódjának tekinthető, mert megőrzi a logi- 
kailag törölt elemek származási helyét. Rengeteg törölt levél 
esetén nem mindegy, hogy egy sík, vagy egy hierarchikus ku- 
kából kell egy-egy elemet visszaszerezni! 


Fóti Marcell 

marcellfonetacademia.net 

A szerző a NetAcademia vezető oktatója 
MCSE, MCT, MCDBA, MZ/X 


http://vilagokorseg.hu 


SZABOTÁZS. AZT MONDTA, 
HOGY ÉJSZAKA VALAKI 
LETÖRÖLTE A FONTOS 
LEVELEZÉSÉT MR. VIAGRÁVAL 
ÉS MR. BIGGER PENIS-SZEL. 
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Biztonságos aláíráskezelő 
alkalmazások 


I. rész: hitelesítések, hitelesítő 


szervezetek 


Az aláíráskezelő alkalmazás olyan szoftver, mely aláírásokat készít és/vagy ellenőriz. Ilyenek például 
az Outlook és Outlook Express levelezőprogramok, melyek elektronikus levelek aláírását és aláírás el- 
lenőrzését végzik. De ilyen a Word, Excel és PowerPoint is, melyek az általuk készített dokumentu- 
mok, sablonok és makrók aláírására, valamint a mások által aláírt állományok aláírás ellenőrzésére ké- 


pesek. 


Az Internet Explorer is képes aláírásra az SSL autentikáció fo- 
lyamán, amennyiben a felhasználó rendelkezik magán- 
kulccsal, és aláírás-ellenőrzésre is, amikor a webszerver (szin- 
tén aláíráskezelő alkalmazás) azonosítja magát hasonlókép- 
pen, illetve ha aláírt szoftverrel (Java applettel vagy ActiveX 
komponenssel) akad dolga. A biztonságos aláíráskezelő alkal- 
mazás olyan alkalmazás, amely az aláírás készítését és ellenőr- 
zését biztonságos módon végzi. Magyarul hacker-álló. 

Az alábbi írás, egy sorozat első cikkeként ilyen biztonságos 
aláíráskezelő alkalmazások fejlesztéséhez kíván segítséget 
adni. 


Az aláíráskezelés biztonsága 


Az aláírás folyamata az aláírói dokumentum kiválasztásával és 
az aláírási szándék aláíró általi jelzésével kezdődik. Ez után az 
aláíráskezelő alkalmazás elkészíti az aláírói dokumentum le- 
nyomatát (hash), majd ezt elküldi az aláírást létrehozó eszköz- 
nek, amely lehet egy intelligens kártya, egy token vagy akár 
egy hardveres biztonsági modul is. Az aláírást létrehozó esz- 
köz azonosítja az aláírót (tipikusan egy PIN kód bekérésével), 
majd a lenyomat magánkulccsal történő kódolásával elkészíti 
az aláírást. Ezt visszaküldi az aláíráskezelő alkalmazásnak, 
amely hozzákapcsolja azt az aláírói dokumentumhoz. 

Ez a folyamat számos módon támadható. Például az aláírói do- 
kumentum kiválasztása után az aláíráskezelő alkalmazás egy 
rossz szándékú beavatkozást követően egy másik dokumen- 
tum lenyomatát készíti el, és küldi az aláírást létrehozó eszköz- 
nek, amiből az aláíró semmit nem érzékel. Vagy egy billentyű- 
zetfigyelő program ellophatja az aláíró eszköznek a számító- 
gép billentyűzetén megadott PIN kódját, amit követően az aláí- 
rási szándék aláíró általi jelzése nélkül is aláírhat bármilyen 
dokumentumot. Az aláírás-ellenőrzési folyamat szintén támad- 
ható. Az ellenőrzés például visszaadhat megfelelő értéket, ami- 
kor egy bizonyos aláíró egyébként nem valódi aláírásával talál- 
kozik, mert az alkalmazás eleve ilyen (így lett kifejlesztve), 
vagy mert valaki módosította azt. 

De nemcsak rosszindulatú beavatkozás jelenthet veszélyt: ma- 
ga az aláíráskezelő alkalmazás is lehet hibás. Például érzékeli, 
hogy az aláírói dokumentum egy Word állomány és megjele- 
níti azt a saját Word megjelenítőjével, vagy a számítógépen ta- 
lálható Word 6.0 szoftverrel. Csakhogy az aláírói dokumentum 
egy későbbi Word verzióval készült, és így egyes részei más- 
képp jelennek meg a dokumentum összeállításakor (amit pél- 


dául a titkárnő végzett), az aláíráskor (amit a főnök úr) és az el- 
lenőrzéskor (amit egy másik partnercég munkatársa végez). De 
az is lehet, hogy a Word dokumentum egy másik nemzeti 
Word verzióval és/vagy egy másik karakterkészlettel készült, 
amelynek következtében az egyes karakterek és számok más 
értékkel jelennek meg. Az aláírói dokumentum egyébként is 
kritikus pont, hiszen aktív kódokat (makrókat) is tartalmazhat, 
amik a megjelenést érdekesen befolyásolhatják, illetve a doku- 
mentum tartalmát is módosíthatják. 
Vagy mi van akkor, ha az ellenőrző számítógép órája rosszul 
jár (véletlen vagy nem véletlen) és egy már lejárt tanúsítványt 
érvényesnek érzékel? Illetve mit tesz 
akkor, ha a tanúsítvány-visszavonási 
lista (CRL) nem érhető el? Folytathat- 


Ma még egy lépéssel nám még a sort további példákkal, 
ett dtn hogy mit lehet elrontani egy 
a rosszfiúk előtt aláíráskezelő alkalmazás tervezése, 


fejlesztése és üzemeltetése során, il- 
letve hol és miként támadható egy he- 
lyesen működő szoftver. Egyelőre a 
cél azonban csak annyi, hogy rávilá- 
gítsak arra, hogy számtalan veszély le- 
selkedik az aláíró és ellenőrző felekre 
az alkalmazás felől is. Ezek a veszé- 
lyek ráadásul sokkal nagyobb kárral 
fenyegetnek, mint azok, amelyeket 
eddig ismertünk: egyes vírusok letö- 
rölhették a merevlemezünket, illetéktelenek hozzáférhettek 
személyes adatainkhoz, idétlen hackerek honlapunkat meg- 
gyalázhatták. 

De mi van akkor, ha egy nem biztonságos aláíróalkalmazás 
minden vagyonunkat átruházza Mr. Ali Capone ugandai állam- 
polgár részére? Vagy ha egy aláírás ellenőrzése során cégünk 
elfogad egy nem valódi megrendelést, melynek hatására le- 
szállít 100 millió forint értékű takarmányt egy jemeni cégnek? 
Hozhatnék persze életszerűbb példákat is, de szemléltetésnek 
ezek is megteszik. 

Elektronikus aláírást máris sok helyen használnak az üzleti 
életben: bankok, kereskedelmi cégek, az államigazgatás egyes 
szervei. Ma még egy lépéssel a rosszfiúk előtt járunk, de ha 
nem lépünk gyorsan tovább, beérnek minket. Ahogy egyre na- 
gyobb összegek forognak elektronikus aláírás által védetten, 
egyre szélesebb körben, úgy éri majd meg egyre nagyobb erő- 


járunk, de ha nem 
lépünk gyorsan 
tovább, beérnek 


minket. 


tárg. Tő. tecnnet 


feszítést tenni a visszaélés érdekében. Némelyik visszaélés pe- 
dig nem is kíván olyan nagy erőfeszítést. A fejlesztők ismeretei 
itt válnak kulcskérdéssé, hiszen anélkül, hogy ismernék a le- 
hetséges visszaéléseket, az ezeket elhárító megoldásokat, sőt 
az elektronikus aláírás alapfogalmait, működési módját, nehe- 
zen elképzelhető, hogy biztonságos aláíráskezelő alkalmazást 
fejlesszenek. 

De nemcsak műszaki ismeretekre van szükség a biztonságos 
aláíráskezelő alkalmazások implementálásához, piaci beveze- 
téséhez, kereskedelméhez vagy beszerzéséhez. A terület rész- 
letes jogi szabályozása miatt a vonatkozó törvények és alsóbb- 
rendű jogszabályok ismerete sem kerülhető el. Mindezen túl, 
az ilyen termékek fejlesztői számára a téma meghatározó nem- 
zetközi szabványainak, ajánlásainak megismerése is elenged- 
hetetlen. 

Jogi háttér 

A jog természetes módon nem a fejlesztőkre bízza, hogy az ál- 
taluk fejlesztett aláíráskezelő alkalmazás biztonságáról ítélkez- 
zenek. Csak egy független ítész szakvéleménye igazolhatja az 
alkalmazás biztonságát. Jól illeszkedik ez a jogi szabályozás 
egyéb előírásaihoz, s megfelel a terméktanúsítás általános gya- 
korlatának. 

Áz elektronikus aláírási törvény az elektronikus aláírás két 
szintjét definiálja: a fokozott biztonságú és a minősített aláírást. 
A fokozott biztonságú aláírás elkészítéséhez és ellenőrzéséhez 
fokozott biztonságú tanúsítvány és aláíráskezelő alkalmazás 
szükségeltetik. Különösebb műszaki követelményeket sem a 
tanúsítvánnyal, sem az alkalmazással szemben nem támaszta- 
nak az előírások. Ennek megfelelően az így létrehozott aláírás 
biztonsága is korlátozott. Nem szeretném azt sugallni, hogy 
nem biztonságos az ilyen aláírás, de körültekintően kell eljár- 
ni a kezelésekor, különösen nagy értékű tranzakciók során 
(melyekre a hitelesítésszolgáltató felelősségvállalása már nem 
is terjed ki). Az ilyenekre jobban megfelelhet a minősített elekt- 
ronikus aláírás, amelyhez három összetevő szükségeltetik. El- 
sőként is a minősített tanúsítvány az ellenőrzéshez, melyet egy 
minősített hitelesítésszolgáltató képes kibocsátani, ahhoz a 
magánkulcshoz, melyet a második összetevővel, a biztonságos 
aláírás létrehozó eszközzel készítettünk. A harmadik összetevő 
a biztonságos aláíráskezelő alkalmazás. 

Mitől válik minősítetté a tanúsítvány? Attól, hogy az azt kiadó 
szolgáltató megfelelt a Hírközlési Felügyelet által végzett vizs- 
gálatoknak, és nyilvántartásba vették. Az eszköz és az alkalma- 
zás pedig attól lesznek jogi értelemben is ,biztonságosak", 
hogy valamely (a 15/2001. MeHVM rendelet szerinti) termék- 
tanúsító szervezet tanúsítja őket. E tanúsítás során az Informa- 
tikai és Hírközlési Miniszter által kijelölt szervezet írásban iga- 
zolja, hogy az elektronikus aláírási termék (hardver vagy szoft- 
ver) megfelel a mértékadó előírásokban meghatározott köve- 
telményeknek. Biztonságos aláíráslétrehozó eszköz tanúsításá- 
ra sor is került már, ilyen termék kereskedelmi forgalomban 
szabadon beszerezhető. Az első biztonságos aláíráskezelő al- 
kalmazásra (szoftver!) azonban még várni kell. 

A jogszabályok nem nevesítik az elektronikus aláírási termék 
biztonságát meghatározó konkrét, általánosan értelmezhető 
műszaki követelményeket. Az említett , mértékadó előírások" 
gyakorlatilag nemzetközileg elismert és alkalmazott szabvá- 
nyokat, ajánlásokat jelentenek. Azt, hogy konkrétan melyeket, 
a tanúsító szervezet döntheti el. A szervezet kijelölési okirata 
tartalmazza ezen előírások megnevezését, de hogy ezek egyes 
előírásait milyen módon és mértékben veszik figyelembe a ta- 
núsító szervezetek, azt csak ők tudják megmondani. A tanúsí- 
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tó szervezetek kijelölést megelőző akkreditálása so- 
rán (melyet az 1995. évi XXIX. törvény szerinti szak- 
mai akkreditáló bizottságok végeznek) ugyan vizsgál- 
hatják, hogy mi alapján és hogyan ítélkezik a szerve- 
zet, de gyakorlatilag sok beleszólása ebbe nincs a ha- 
tóságoknak. 


A tanúsítás és a tanúsítvány 

Egy tanúsító szervezet által kiadott igazolással (tanúsítvánnyal) 
rendelkező elektronikus aláírási termék esetében az ellenkező 
eset bizonyításáig vélelmezni kell, hogy a termék biztonságos, 
és megfelel az igazolásban megjelölt egyéb követelmények- 
nek. Egy ilyen igazolás sem mindenható azonban. A tanúsító 
szervezetek sem estek a fejük lágyára, hogy egy pecséttel kö- 
rülményektől és felhasználási módtól függetlenül biztonságos- 
nak minősítsenek egy eszközt vagy alkalmazást. Az általuk kia- 
dott tanúsítvány részletesen leírja, hogy a kérdéses termék pon- 
tosan milyen funkcionalitással és konfigurációban, milyen fel- 
tételek teljesülése esetén, mire használható. 

Például egy biztonságos aláíráslétrehozó eszköz alkalmas le- 
het minősített elektronikus aláírás létrehozására, a tanúsítvány 
mellékletében megfogalmazott biztonsági tulajdonságokkal és 
beállításokkal, a szintén részletesen leírt felhasználási feltéte- 
lek megléte esetén. Ugyanígy egy hardveres biztonsági modul 
alkalmas lehet elektronikus aláírás hitelesítési szolgáltatás ke- 
retén belül minősített tanúsítványt hitelesítő szolgáltatói kul- 
csok generálására és tárolására, valamint minősített tanúsítvá- 
nyok aláírására. 

Ugyanez a modul időbélyegző szolgáltatás keretén belül alkal- 
mas lehet időbélyegzőt aláíró szolgáltatói kulcsok generálásá- 
ra és tárolására, valamint időbélyegzők aláírására. Egy bizton- 
ságos aláíráskezelő alkalmazás pedig a tanúsítvány szerint al- 
kalmas lehet minősített elektronikus aláírás létrehozásában és 
ellenőrzésében történő felhasználásra. Az, hogy a tanúsítás mi- 
re minősíti alkalmasnak a terméket, a tanúsítást kérőtől is függ: 
neki kell megmondania, hogy a termék milyen felhasználásra 
való alkalmasságának vizsgálatát kéri. A fokozott biztonságú 
aláírás létrehozásában és ellenőrzésében szerepet játszó esz- 
közök és alkalmazások erre való alkalmasságának tanúsítását a 
jogszabályok nem követelik meg, de ezek gyártói szabad elha- 
tározás alapján mégis élni szoktak az önkéntes tanúsíttatás le- 
hetőségével. 
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A HUNGUARD Számítástechnikai-, informatikai kutató-fejlesztő és általános szolgáltató KI. a 
15/200L.(VIII. 27.) MEHVM rendelet alapján, mint a Magyar Köztársaság Informatikai és 
Hírközlési Miniszter 006/2002 számú kijelölési okiratával kijelölt terméktanúsító szervezet 





tanúsítja, 
hogy az 
IBM Corp. 
által előállított és forgalmazott 


eljesűléve, madam 
betöltése esetén 


megfelel 
minősített hitelesítés-szolgáltató által végzett 
alábbi tevékenységek biztonságos elvégzéséhez: 


hitelesítés szolgál 
(Minősített) tanúsítvány lcsok generál; 
tanúsítványok és helyreállítására: 





Időbélyegzés szolgáltatás keretén belül: 
Időbélyegző aláíró kulcsok generálására. tárolására, időbé 
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hitelesítések, hitelesítő szervezetek / 
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Biztonságos aláíráskezelő alkalmazások - 
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! A tanúsítás során a tanúsító szervezetek szinte kizá- 
rólag csak dokumentumok és tesztek alapján dolgoz- 
nak. A felhasznált dokumentumok között megtalál- 
hatók a gyártó saját (igen mély szintű) leírásai a ter- 
mékéről, és független laboratóriumi vizsgálati jelen- 

tések is. A tanúsítási eljárás nem egyezik meg ugyanakkor a la- 
boratóriumi vizsgálattal, ez két különböző eljárást jelent, me- 
lyet végezhet akár egy cég is. Ez utóbbihoz azonban igen költ- 
séges eszközök lehetnek szükségesek, s egy-egy vizsgálat el- 
végzése nagyon sok időt emészthet fel (némely esetben olyan 
sokat, hogy közben elavulhat a termék). Valószínűleg ennek is 
köszönhető, hogy Magyarországon jelenleg ilyen laboratórium 
nem létezik, s a tanúsító szervezetek kizárólag külföldi labor- 
jelentések alapján dolgoznak. Ez a magyar termékeknek hát- 
rány, de nem feltétlen akadály: laborlelet hiányában is kiadha- 
tó a tanúsítás. Ez esetben a tanúsítás során nyilván erősebb sze- 
repet kapnak a tesztek és a gyártó saját dokumentációi. A ter- 
mékhez kiadott tanúsítvány azonban messzemenően tükrözi, 
hogy mi alapján lett kiadva. És ez nemcsak a tanúsító szerve- 
zet felelősségének korlátozása miatt van így, hanem a felhasz- 
nálók biztonsága miatt is. Ha a tanúsítást nem alapozta meg 
részletes laborjelentés, az a tanúsító bizonytalanságát nyilván 
növeli, és ez a felhasználást korlátozó feltételek és körülmé- 
nyek kiterjedésének növekedését okozhatja a tanúsítványban. 
Egy aláíráskezelő alkalmazás esetében a feltételek között meg- 
találhatók előírások az alkalmazás futtatási környezetére (a 
hardverre, az operációs rendszerre és egyéb programokra, a 
hálózati kapcsolatokra), a beszerzés, installáció, üzembe he- 
lyezés és üzemből történő kivonás módjára, a működtetés 
módjára (hogy az például megakadályozza vírusok, trójai falo- 
vak és billentyűzetlopó programok jelenlétét), az aláíráskezelő 
alkalmazással kapcsolatban lévő alkalmazásokra vonatko- 
zóan. A kiadott tanúsítvány a termék egy konkrét verziójára vo- 
natkozik, másik verzióra (legyen az akár későbbi is) nem. De 
nemcsak verzióhoz, hanem konfigurációhoz is kötődik a tanú- 
sítvány. Egy intelligens kártya például csak akkor minősülhet 
biztonságos aláíráslétrehozó eszköznek, ha a kártyán egy adott 
mikrochip, egy adott operációs rendszerrel, és egy adott aláí- 
rás-létrehozó alkalmazással (kártyán implementált aláíró szoft- 
verrel) együtt működik. Ha bármelyikből egy másik verzió ke- 
rül a kártyára, a tanúsítvány nem feltétlenül érvényes. Ezért 
ilyen eszközök felhasználása előtt mindenképp ajánlott körül- 
tekintően elolvasni a tanúsítványt, és ellenőrizni az egyes fel- 
tételek meglétét és teljesíthetőségét. A tanúsítványhoz tartozni 
szokott egy tanúsítási jelentés is, melynek hasonlóan részletes 
áttanulmányozását csak szakembereknek ajánlom. Ez a doku- 
mentum a termék tulajdonságait majdnem egy laboratóriumi 
jelentés részletességével taglalja. Célja, hogy pontosan alátá- 
massza a tanúsítvány egyes megállapításait. 


Európa és egyebek 


Az Európai Unióhoz való csatlakozás ezen a területen is válto- 
zásokat fog hozni: ha egy az Unió valamely tagállamában nyil- 
vántartásba vett tanúsító szervezet ad ki igazolást az elektroni- 


kus aláírási termék biztonságos voltáról, az hazánkban is auto- 


jö matikusan biztonságosnak fog számí- 


tani. És ugyanígy egy hazánkban kia- 
dott tanúsítvány is automatikusan ér- 
vényes lesz az egész Unióban. 

Az, hogy mely szervezetek jogosultak 


Az elektronikus 


aláírási törvény az tanúsításra, és mely termékekre vonat- 
kozóan adtak ki valamilyen szintű ta- 
elektronikus aláírás núsítványt, a Hírközlési Felügyelet 
(Interneten keresztül elérhető) hatósá- 
két szintjét gi nyilvántartásából derül ki. A nyil- 


vántartásba vétellel egyidejűleg a 
Felügyelet azonosítójelet is ad a ter- 
mékeknek, amelyre a gyártó hivatkoz- 
hat. A Felügyelet szerepe az elektroni- 
kus aláírási termékekkel kapcsolato- 
san azonban kimerül a különböző a 
nyilvántartások vezetésében. A tanúsí- 
tó szervezetek kijelölését illetően a ta- 
núsítás kritériumai (vagyis a termékek műszaki tulajdonságai- 
nak) tekintetében, és a tanúsítási módszer kapcsán nincs sem- 
milyen szerepe, jogköre. Fontos garanciális szabály, hogy a ta- 
núsítószervezet nyilvántartásból való törlése nem érinti az álta- 
la korábban kiadott igazolások érvényességét. 


definiálja: a fokozott 
biztonságú és a 


minősített aláírást. 





Almási János 
Janos. Almasi€ohu.ibm.com 


ITELT 

1999/93/EK irányelv az elektronikus aláírások közösségi keretszabályairól ] 
2001. évi XXXV. törvény az elektronikus aláírásról 

15/2001. MeHVM rendelet az elektronikus aláírási termékek tanúsítását végző 
szervezetekről, illetve a kijelölésükre vonatkozó szabályokról. 

16/2001. MeHVM rendelet az elektronikus aláírással kapcsolatos szolgáltatásokra 
és ezek szolgáltatóira vonatkozó részletes követelményekről. 

151/2001. Kormányrendelet a Hírközlési Felügyeletnek az elektronikus aláírással 
kapcsolatos feladat- és hatásköréről, valamint eljárásának részletes szabályairól. 
20/2001. MeHVM rendelet a Hírközlési Felügyeletnek az elektronikus aláírással 
összefüggő minősítéssel és nyilvántartással kapcsolatos tevékenységéért 

fizetendő díjakról. 

2/2002. MeHVM irányelv a minősített elektronikus aláírással kapcsolatos szolgál- 
tatásokra és ezek szolgáltatóira vonatkozó biztonsági követelményekről. 
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Mátrix Kft. http://www.matrix-tanusito.hu 
Hunguard Kft. http:/www.hunguard.hu 
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Negyedik rész — XSLT mint 
prezentációs réteg 
Nyugodtan mondhatjuk, hogy a modern portálmegoldások alapját az adatrétegtől az üzleti logikán át 


a prezentációig az XML és az XSLT adja. Most nézzük meg, hogyan szolgál minket az XSLT- 
transzformáció, ha az átlagosnál furmányosabb felhasználói felületet kell előállítanunk. Ha jól csinál- 


juk, szabványos és az üzleti logikától teljesen leválasztott prezentációs réteget kapunk. 


Az előző részt egy olyan példával fejeztük be, amelyben egy 
XSLT-megjelenítő olyan HTML-t generált, amelyben egy táblá- 
zat sorai váltakozó színnel jelentek meg, és a kurzor mozgása 
is követni tudtuk (highlight). Folytassuk most ennek a példának 
a részletes leírásával, és mélyedjünk bele a változók és para- 
méterek használatába! 


Változók és paraméterek 42 


A legszembetűnőbb eltérés a megszokottól, hogy az XSLT- 
változók csak egyszer kaphatnak értéket. Viszont a feladatuk is 
más, mivel nem egyszerű adatot tárolnak, hanem XML-részfát. 
Általában persze (mint itt a példában is), egy-egy érték tárolá- 
sára használjuk (egy darab text-node-ot tartalmazó fa). Ha sab- 
lonban deklaráljuk, csak lokálisan, ha sablonon kívül, globáli- 
san is felhasználhatjuk őket. Előző cikkünk legutolsó példájá- 
ban a szín kiválasztása a "position() xpath függvénnyel történik 
(előző cikk utolsó listájának 4. sora). Ez csak akkor használha- 
tó, ha a sablont szelekción keresztül hívjuk (azaz apply- 
templates utasítással), ugyanis a szelekció az, amely listát ké- 
pez, és csak ebben értelmezett a pozíció. Ha a hívás az alábbi 
módon történik, a sablonban a "position()" függvény mindig 1- 
et ad vissza: 


cxs1l:for-each select-"Company"5 
cxsl:apply-templates select-"."5 

$/xs81:for-each: 

cxs1l:template match-"Company"5 


c/xs81:templates 


Ez esetben a "for-each" összeállít ugyan egy node-list-et, és be 
is járja (iterálja) azt, viszont a hívott sablonba már csak olyan 
halmaz kerül, amelynek egyetlen eleme van. Ebben az esetben 
használhatunk paraméterezett sablont. Mivel a "for-each" ciklu- 
son belül tudjuk a pozíciót, átadhatjuk ezt a sablonnak a "with- 
param! utasítással. A paramétert a sablonban deklarálni kell az 
"xsl:param" utasítással. A paraméter felhasználása megegyezik 
a változóéval: 


cxs1l:for-each select-"Company"5 
cxs1l:apply-templates select-"."5 
cxsl:with-param name-"pos" select-"position()"/5 
c/xs1l:apply-templatesz 
c/xs1:for-each: 
cxs1l:template match-"Company"5 
cxs1l:param name-"pos"/5 
cxs1l:value-of select-"$pos"/5 


c/xs1l:templates 


Változókat mindenhol célszerű használni, ahol már előre ki- 
számolt dolgot újra fel kell használni. Az XSLT instant változói 
csak egyre nem jók: el kell felejtenünk az i-—i--1 típusú progra- 
mozást. Az XSLT automatizmusai miatt általában el lehet kerül- 
ni a változók használatát, de van egy-két helyzet, amikor min- 
denképpen használnunk kell. Ilyen például az az eset, amikor 
egy sablonon belüli szelekcióban használnunk kell a sablon 
context-node-jának pozícióját. Ekkor ugyanis a szelekcióbeli 
position() függvény a leválogatandó halmaz elemeire vonatko- 
zik. Ekkor a szelektálás előtt egy változóban elhelyezzük a 
context-node pozícióját, majd a válogatáskor a változót hasz- 
náljuk fel. Erre később látunk egy példát. 

Végül egy érdekes trükk a változók használatához: az XSLT- 
függvény megvalósítása. Az alábbi lista megjeleníti az előző 
cikkünkből jól ismert céglistát, majd a végére egy hosszú cel- 
lába kiírja a globális paraméterben kapott dátumot. A cella 
olyan hosszú lesz, mint a táblázat, amit az adott TD "colspan" 
attributumában állítunk be. 


1. cxsl:template match-"Companies"5 
2. ,xTABLE BORDER-"1"5 


310 cxs1l:variable name-"columns": 
4. cxs1l:call-template name-"getColumns" /: 
5. c/xs1l:variables 
(o cx8s1l:apply-templates select-"Company" /5 
7. STR. 
8. LTD: 
Cs cxsl:attribute name-"colspan"5 
OS cxs1l:value-of select-"$columns" /5 
éa c/xsl:attributes 
12. cxsl:textodate: c/xsl:text: 
3 cxs1l:value-of select-"$date" /5 
14. £/TD3 
15. £/TR: 


16.  c/TABLE5 

17. c/xsl:templates 

18. cxsl:template name-"getColumns"5 

19.  cxsl:value-of select-"count(Company[1]/$)" /5 
20. c/xsl:templates 


A lényeg a 3-5. sorokban van. Ez tulajdonképpen az XSLT-beli 
függvény. A "getColums" sablon (18-20. sorok) megszámolja az 
első "Company" elem gyerekelemeit (vegyük észre, hogy a 
"call-template" utasítással hívott sablonban nem változik meg a 
context-node). Kimenete egy egész szám, amely alapállapot- 
ban hozzáadódna a kimeneti fához, mint text-node, itt azon- 
ban ezt az értéket lenyeli a változó, és ezt azután máshol hasz- 
náljuk fel. 


Piszkos elemek és fehér foltok 


Említettük, hogy XML-jeinket célszerű úgy megtervezni, hogy 
azok objektumok és property-k hierarchiáját írják le. Ha így já- 
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runk el, ebből az a fontos tény következik, hogy ele- 
mi adat csak attribútumban, illetve legalsó szintű 
(leaf) elemben lesz. Az ilyen szerkezetre nagyon 
könnyű XSLT-t írni. Az élet viszont bonyolult, mint 
mindig. A való világ produkálja például a html-féle 
szövegmegjelenítést, amely nem ilyen felfogásban dolgozik. 
Például az ca: tag egy linkobjektumot reprezentál, melynek 
minimum van egy "href", és egy (mondjuk) title property-je, 
amely a tag text node-ja. Viszont a title tartalmazhat struktúrát 
is, pl. képhivatkozást, és szöveget vegyesen. Az ilyen eleme- 
ket, amelyek alelemeket és szöveg node-okat egyaránt tartal- 
maznak, piszkos elemeknek (dirty nodes) szoktuk nevezni. 
XML-jeink tervezésekor célszerű kerülnünk ezt a megközelí- 
tést, de minden nagyobb alkalmazás előbb utóbb szembesül 
ezzel a problémával, ha máskor nem, a gyors bővítéskor. 
Előfordulhat az is, hogy a kimenő html-be át kell vinni az ere- 
deti soremeléseket, tab karaktereket, és a többszörözött szókö- 
zöket (white spaces). A html, alapműködése szerint, e három 
fajta karakter egymás utáni előfordulásait egy szóközzé vonja 
össze (strip spaces). 

Alkalmazásunk kétféleképpen kezelheti az ilyen anyagot. Egy- 
részt megtehetjük, hogy a piszkos elemek text node-jait egy er- 
re a célra kitalált pl. ctext: elembe zárjuk, valamint kitalálunk 
bizonyos elemeket a "fehér" karakterekre is. Ez esetben az 
XSLT-vel nincs gond, mindent logikával kezeltünk le. A másik 
esetben kötünk egy kompromisszumot. Kinevezünk egy ele- 
met, amelyben engedélyezzük a szöveg keveredését az al- 
elemekkel, és olyan XSLT-t írunk, amely ebben az elemben át- 
viszi a fehér karaktereket is. 

Alább látható egy XML-fájl úgy, hogy a szerkesztőben be van 
kapcsolva a whitespace megjelenítés. 








£?xml"versions"1.0"" encodings"iso-8859-2"" ?2 
LKOOTI 

3 cbekezbbl::két-szó. 

£/bekezb 

53 dbekezbb2:"új"sor 

3 3 tab-ok"-és"-ssss szóközök. 

£€/bekezb 

3 fbekezb3: "egyéb" formázás: 

CboldbAz" alábbi: linken:C/boldbc$160; 
€xlink"url-"http://msdn. microsoft. com"5 

http: //msdn. microsoft. comCc/linkoc$160; 
Cboldotovábbi: információk" érhetők:el.C/boldcs160; 
€/bekezb 

3 Cbekezbb4: "záró: sor. 

£/bekezb 

£x/roots 
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E1 Whitespace-k a szerkesztőben 


Ez a struktúra olyan bekezdéseket képes leírni, amelyek szöve- 
gen kívül hiperlinket és egyfajta kiemelést (cbold5) tartalmaz- 
hatnak. Érdemes megfigyelni, hogy a záró c/bekezds elemek 
mindig új sorban vannak, mivel jelenleg a zárótag előtti sore- 
melés is értékes karakter. 

A cbekezds elem megjelenítése legegyszerűbben a html 
apres elemével történhet, mivel az megőrzi a fehér karaktere- 
ket. A megjelenítő fontos sorai: 
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A piszkosságot egy olyan szelekcióval oldjuk meg, amely kivá- 
lasztja a szövegeket és az alelemeket is úgy, hogy a sorrendjük 
megmarad (7. sor). 

Itt felmerül egy olyan probléma, ami nem teljesen magától ér- 
tetődő. Az olyan text node-ok, amelyek kizárólag white- 
space-t tartalmaznak, hiányoznak a fenti szelekcióból. Ha ez 
nem így lenne, minden olyan XML, amely indentálva van a 
szerkesztőben, egy csomó piszkos elemet tartalmazna, mert az 
enter-tab is text- node lenne. 

Viszont nem az, és nem is szelektálható ki. Ez az ok, amiért 
célszerű kerülni a piszkos elemek használatát: mivel keveredik 
a szerkesztőnek szánt metainformáció (indentálás) az értékes 
adattal. Ha muszáj használnunk ezt a technikát, korlátozzuk 
azt bizonyos elemekre. A fenti példában lévő 84160; karakter- 
sorozat ezt a problémát hivatott megoldani. A záró és nyitó ta- 
gok közötti soremelés ugyanis nincs benne a szelekcióban, 
számunkra viszont jelenleg értékes karakterek. Ez a string vi- 
szont (amely egyébként a html-beli nbsp; megfelelője) érté- 
kes, bár láthatatlan tartalommal látja el az adott helyet és így 
kiválasztható text-node lesz belőle. Ezt a láthatatlan karaktert 
egyébként már az XML első felhasználásakor el kell helyezni, 
mivel a fent leírtak a DOM-mal való munka folyamán is érvé- 
nyesek. 

Ha nem használható olyan html elem, amely megtartja a fehér 
karaktereket (p!/ a fenti cpre:), nincs mese, át kell őket valami- 
lyen más stringre transzformálni. A soremelést célszerű cbr/5 
elemre, a tab-karaktereket pedig szóköz sorozatra cserélni. A 
szóközöknél nem elég a 32-es kódú karaktersorozat, mert ha 
abból egynél több van, azt a html , lenyúlja" (strip-space), de 
például használhatunk felváltva 32-es és 160-as karaktereket. 
A transzformálást legegyszerűbben XSLT-scripttel tudjuk meg- 
tenni. 


Script a scriptben 


Az XSLT-ben két esetben célszerű scriptet használni: 
HA Ha az adott scriptnyelv segítségével egy bizonyos áta- 
lakítási funkció könnyebben hajtható végre. 
TA Ha mindenképpen iteratív algoritmusra van szüksé- 
günk 
Script használatához alkalmaznunk kell az "urn:schemas- 
microsoft-com:xslt" névteret, valamint szükség van egy másik 
prefixre a hívás számára. A scriptet CDATA blokkba zárjuk és 
az e célra fenntartott XSLT-elembe helyezzük. Íme a karakter- 
csere megvalósítása javascript segítségével: 





tech.net 


disable-output-escaping-"yes" 
select-"j:replacer(string(.))" /: 
c/xsl:templates ... 


A script többféle nyelvet használhat, sőt ha több script elemet 
alkalmazunk (többféle prefixszel), azok mindegyike más-más 
nyelvű lehet. Csak hogy ne legyen teljesen felhőtlen a dolog: a 
nyelvek használata függ attól, hogy milyen környezet futtatja a 
transzformer objektumot, például az Explorer nem ismeri a Ctt 
scriptet, a .NET viszont nem szereti a vbscriptet. A javascript 
az, amelyet mindkét esetben lehet futtatni, ez platformfügget- 
len scriptnyelv az XSLT-ben. A .NET környezet viszont lehető- 
vé teszi, hogy az általa támogatott scriptnyelveket használva 
(VB és C8) elérjük a framework névtereit. Erre egy jó példa az 
alábbi script, amely az aktuális hosszú dátumot jeleníti meg 
úgy, hogy annak nyelvét az XML-ből kapott adat (vagy akár 
külső paraméter) alapján állítja be. 

1. cmsxsl:script implements-prefix-"script" 

languagez"CSharp"5c! [CDATA[ 
2. public string GetDate(string sLangCode) 
4 Tee cname -— ""; 


5. string pattern - ""; 
6.  switch(sLangCode) 


SZESZ 

.8B. case "hu": 

9. cname - "hu-HU"; 

10. pattern - "yyyy. MMMM d., dddd"; 
1 break; 

12. case "en": 

13. cname - "en-US"; 

14. pattern - "dddd, MMMM dd, yyyYy"; 
15. break; 

GÉNEB 


17.  System.Globalization.Culturelnfo ci - 
System.Globalization.Culturelnfo. 
WecreateSpecificCulture(cname) ; 
18. ci.DateTimeFormat.LongTimePattern — " "; 
19. ci.DateTimeFormat.ShortDatePattern - pattern; 
20. return DateTime.Now.ToString(ci); 
21. )]]5c/msxsl:script: 


Azzal lehet vitatkozni, hogy a kiírandó dátum-string előállítása 
a prezentáció feladata-e, jelen esetben a példa kedvéért ezt így 
oldottuk meg. A webszerver (csodák csodájára) csak egy bizo- 
nyos területi beállítással rendelkezik, ám ez a scripttel tetsző- 
leges nyelven kiírhatja a dátumot, mivel a hónap és napneve- 
ket a rendszer szolgáltatja (természetesen csak a telepített terü- 
leti beállítások jöhetnek szóba). 


Famegjelenítés tárolt fából faobjektumon keresztül 


Sokszor lehet olyan feladatunk, hogy fastruktúrát kell megjele- 
nítenünk, például sitemap, szervezeti felépítés, vagy bármilyen 
többszintű kategorizálás céljából. Az eddigiek alapján joggal 
gondolhatjuk, hogy egy fa megjelenítése nem okozhat különö- 
sebb gondot. Az XML-ben kapunk egy fát, és a kimenet is fa 
lesz. Ha a fa csomópontjai ugyanolyan nevűek, egy sablonnal, 
és annak rekurzív hívásával elintézhető az egész. Ez így is len- 
ne, ha az élet egyszerű lenne. Tekintsük a következő feladatot. 
Van egy olyan szájtunk, amelyben az oldalak hierarchikus 
szervezésűek. Jelenítsük meg fastruktúrában az oldalakat úgy, 
hogy mindegyik fa elem olyan link legyen, amellyel közvetle- 
nül az oldalra tudunk ugrani. A fa alapállapotban csak az első 
szintig legyen nyitva, és az ágak nyithatók és zárhatók legye- 
nek és jelenítsék meg a régebbi windows intézőkben megszo- 
kott vonalakat is. Az oldalak csak logikailag léteznek, megjele- 
nítésüket egyetlen fizikai oldal, mondjuk a GetPage.aspx vég- 
zi, amely egyetlen paraméterként az oldal egyedi nevét kéri. 
Az oldalakat SOL táblában tároljuk, egy oldal egy sor, a fa- 
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struktúrát az ugyanerre a táblára mutató ParentID segítségével 
hozzuk létre, amelynek nulla értéke jelzi, hogy ő egy gyökér- 
oldal. 














gijreszt Szájt 
A-B Főoldal 
A [B Eiső oldal 
[B Második oldal 
B Harmadik ol. 
Negyedik oldal 
(B Ötödik oldal 
B.B Adminisztráció 
Rendszerhiba 
d 
E] file:7/7c:HDocuments and Setti[ [0 [E My computer B 








5 Dinamikus sitemap 


Mivel SOL lekérdezéssel hatékonyan csak listákat tudunk 
előállítani, kövessük a jól bevált módszert, kérjünk egy "for 
XML auto, elements" listát az oldalakról, és eresszünk rá egy 
transzformert, amelynek kimenete már fa lesz. Ezen dolgozik 
egy kicsit az üzleti réteg, majd jöhet a megjelenítés. A lekérde- 
zés eredménye ilyen elemekből áll: 


ctblPagesz 
cPageID:31c/PageID: 
cParentID50c/ParentID? 
cNamerMainPagec/Name: 
cTitlesFőoldalc/Titles 
c/tblPagesz 


Ebből a listából egy ilyen fa készül: 


cSite name-"TestSite" title-"Teszt Szájt"5 
cPage name-"MainPage" title-"Főoldal": 
cPage ... 

c/Pagez 

c€/Sites 


A listából a fa elkészítésének lényege annyi, hogy első menet- 
ben a sablonhíváskor leválogatjuk azokat a tblPages elemeket, 
amelyeknek a ParentID elemük értéke 0: 


cxs1l:apply-templates 
select-"tblPages[ParentID - 0]" /:5 


Ezután a sablonon belül azokat válogatjuk, amelyek ParentlD- 
je a context PagelD-jával egyezik meg. Itt arra kell vigyázni, 
hogy az "én azonosítómat az ő szülőjével" hasonlítjuk össze, 
tehát vagy be kell vezetni egy átmeneti változót, vagy pedig 
használni kell a "current(" függvényt: 

cxsl:apply-templates 


select-"../tblPages[ParentID - 
current ()/PageID]" /5 


A current() függvény nem ugyanazt jelenti, mint a "." karakter. 
A szögletes zárójelbe írt "./PagelD" a szelektálandó elemre néz- 
ve, míg a függvény a context-re nézve relatív xpath-t jelent, így 
az előbbi szelekció üres, hacsak nincs olyan oldal, amely ön- 
maga alá van kategorizálva (ekkor a rekurzió végpontja a fizi- 
kai memória méretétől függ). 

Az így növesztett fát esetleges egyéb feldolgozás után küldhet- 
jük a megjelenítőnek. A megjelenítőt nem közöljük teljes ter- 
jedelmében, mivel a maga 168 soros hosszával az alsó-közép- 
kategóriába tartozik (letölthető az [XSLTFAJ címről). Ami ér- 
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dekes benne, az a kis ikonok előtti vonalak, elágazá- 
sok megjelenítése. A vonal nélküli fák megjelenítése 
legegyszerűbben egymásba ágyazott cUL5 aLI5 ele- 
mekkel valósítható meg, mivel a kapott szerkezet 
belső reprezentációja és megjelenése is fa lesz (per- 
sze a stílusukon csiszolni kell egy kicsit, de hát erre való a 
css). A nyitás-zárás miatt ennek így is kell lennie (adott ágra 
kattintva annak el kell tűnnie, illetve meg kell jelennie). 
Viszont a vonalas fa megjelenésében már nem fa, hanem táb- 
lázat, mivel a csomópont mélységétől függően megfelelő szá- 
mú bevezető képet kap a logikailag értékes elem előtt. A bel- 
ső ábrázolás viszont fa kell maradjon. A megoldás ötlete a kö- 
vetkező: a csomópontot megjelenítő sablon kapjon egy para- 
métert, amely szerint azokat a kis képeket jeleníti meg, ame- 
lyeket a szülőjének is meg kellett, plusz egyet, amely a szülő- 
re jellemző. Ez nulla vagy több, függőleges vonalat, vagy üres 
helyet jelent. Ezután megvizsgáljuk, hogy a context utolsó 
elem-e, hogy van-e gyereke és hogy nyitva van-e, majd ezek- 
től függően kiadjuk a megfelelő kis képet, a plusz-mínusz je- 
let és a linket is. 

Ezek után jöhet az oldalra mutató link, ikon és a cím. A beve- 
zető vonalak és üres helyek megjelenítésekor nem kerüljük el 
az áhított iteratív ciklus használatát, amelynek egy megvalósí- 
tása lehet az alábbi sablon: 


wa] 


1. cxsl:template name-"treelines"5 

2. cxsl:param name-"images"/5 

3.  cxsl:choosesz 

4. cxsl:when 

test-"substring($images,1,1) z "1""5 
5. c,IMG BORDER-"O" ALIGN-"middle" 
SRC-"images/line.gif" /: 

6. c/xs1l:whens 

377 sxsl:otherwises 

8. cLxIMG BORDER-"0" ALIGN-"middle" 

SRCs"images/spc.gif" /5 

9. c/xs1l:otherwises 
10. c/xsl:choosez 
11. cxsl:if test-"string-length($images) !z 1"5 
12. cxs1l:call-template name-"treelines"5 
138 cxs1l:with-param name-"images": 
14. cxs1l:value-of 

select-"substring($images,2)"/5 

15. c/xs1l:with-param; 
16. $/xs1l:call-templatez 
17. c/xsl:ifs 
18. c/xsl:templates 


A 2. sorbeli "images" paraméter fogja reprezentálni a képeket 
úgy, hogy a benne lévő string egy karakterének "1" értéke vo- 
nalat, egyéb értéke üres helyet jelent. A 4-10. sorok a string el- 
ső karakterét megvizsgálva elintézik az arra vonatkozó képet, 
ha ezen kívül van még karakter (717. sor) a sablon önmagát 
hívja a fennmaradó stringgel. A paraméter úgy épül, hogy a 
csomópont az alcsomópont hívásakor egy karakterrel bővíti 
az értéket aszerint, hogy ő maga utolsó az adott szinten vagy 
sem. 


Még több XPath 


Az eddigi példákból látszik, hogy az XSLT egyik legnagyobb 
erőssége a fejlett szelektálás lehetősége, és az arra alkalmazha- 
tó automatikus sablonvégrehajtás. Akkor könnyítjük meg a sa- 
ját munkánkat, ha eleve így tervezzük meg a megjelenítés me- 
netét. A következő példánk egy olyan lista kivitele, amely 
hosszú, de relatíve keskeny, ezért több oszlopban kell megje- 
lenítenünk, melynek számát az XSLT objektum paraméterben 
kapja (columns). Mivel az egyes elemek logikailag nem függe- 
nek össze, az XML-ben nincs semmilyen csoportosítás. 
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A feladatot iteratív felfogásban például úgy oldhatnánk meg, 
hogy veszünk egy ciklust, amely végigmegy az elemeken, és 
ebben, ha az elem sorszáma osztható az oszlopok számával, 
elkezdünk egy új sort: leírjuk a "TR" elem nyitótagját. Ezután 
kiírjuk a cella elemet "TD" elembe, majd még egy vizsgálat, és 
ha a cella a sor utolsó eleme, lezárjuk a TR elemet. (Ez az el- 
rettentő példa, XSLT-vel ezt nem így kell csinálni.) 


cxs1l:template match-"item"5 

cxsl:if testzc"((position()-1) mod $columns) - 0"5 
cxs1l:text disable-output-escaping-"yes"5 

$elt;TRegt;c/xsl:text; 

c/xsl:ifs 

cxKTD:3cxsl:value-of select-"."/5c/TD3 

cxsl:if test-"(((position()-1) mod $columns) - 

($columns - 1)) or (position() - last())": 

cxs1l:text disable-output-escaping-"yes": 

belt;/TRegt;c/xsl:texts 

c/xsl:ifs 

c/xs1l:templatez 


Mivel az XSLT-ben a vizsgálat (-xsl:if) is egy XML részfa, a 
csonka nyitó, és záró "TR" elemet csak szövegként vihetjük ki. 
Inkább XSLT-s gondolkodás a következő: Az első szinten kivá- 
lasztjuk a sorelsőket, majd azok a saját sablonjukban az aktuá- 
lis sor celláit. Így tehát két sablonunk lesz (illetve plusz egy a 
lista gyökérelemére). 


1. 
2. 


cxsl:param namez"columns"!"/5 
cxsl:template match-"list": 


3. ,TABLE BORDER-"1"5 
4. cxsl:apply-templates mode-"row" 
5 select-"item[((position()-1) mod 
W$columns) z 0]"/s 
6.  c/TABLE: 
7. c/xs1l:template: 
8. cxsl:template match-"item" mode-"row"5 
9.  cxsl:variable name-"pos" 
10. select-"position()"/: 
11. cTR5 
12. cxs1l:apply-templates mode-"cell" 
Eli select-"../item[((position() egt; 
W($pos - 1) $§ $columns) and 
$W(position() elt;z $pos t $columns)]" /5 
14. c/TR5 
15. c/xsl:templatez . 
16. cxsl:template match-"item" mode-"cell": 
17.  cTD5cxsl:value-of select-"."/5c/TD5 
18. c/xs1l:templatez 


Mivel sorelsők és a cellák ugyanazon XML elem két különbö- 
ző megjelenései, a két sablon ugyanazzal a névvel ,matchel", 
most  megkülönböztetésre "mode" attributumot használjuk. 
Sorelsők (5. sor) azok az elemek, amelyek sorszáma osztható a 
"columns" paraméterrel. Láthatjuk, hogy a position() függvény 
1-es értéktől számoz, hiszen valaminek kell 1-től kezdődnie 
most, hogy a VB.NET is átvette a 0-tól való számozást... A 
sorelsőkre a mode attributum miatt a 8. sorban kezdődő sab- 
lon illeszkedik. A soron belüli cellák azok lesznek, amelyek 
sorszámai e sablon context-jétől a következő sorelső előtti ele- 
mig tartanak (13. sor). A 9. sorban ismét használnunk kell a 
position(-mentés technikáját, mivel az utána következő sze- 
lekció többször is használja ezt az értéket. Végül a 16. sor lesz 
az a sablon, amely megjeleníti az egyes cellákat. 

A fenti módszer az elemeket sorfolytonosan viszi ki. A másik 
lehetőség a hasábszerű megjelenítés. Ezt kétféleképpen lehet 
megoldani. Az egyik szerint egy külső egysoros táblázat bur- 
kolja a listát, amelynek a paraméterben megadott mennyiségű 
oszlopa van, és az egyes cellái egy-egy belső táblázatot tartal- 


maznak a szükséges mennyiségű listaelemmel. A másik megol- 
dás egy táblázatot használ. Először kiszámolja a szükséges so- 
rok számát: 

cxsl:variable name-"rows" 
select-"ceiling(count(item) div $columns)"/5 

Ezt a paramétert megkapja az összes al-sablon. Ezután jöhet a 
sorelsőket feldolgozó sablon hívása: 


cxsl:apply-templates select-"item[position() elt;- 
$rows]" mode-"row": 


A sorelsők sablonbjában pedig így történik az adott sor összes 
cellájának kiválasztása: 
cxs1l:apply-templates mode-"cell" 


select-"../item[(position() mod $rows) - 
$ ($pos mod $rows)l"/: 


A teljesség kedvéért meg kell említeni, hogy ez a két leírt lista- 
megjelenítési módszer hiányos, mivel nem foglalkozik a záró 
üres cellák kérdésével. Ha ugyanis a listaelemek száma nem 
osztható az oszlopok számával, az utolsó elem után üres cel- 
lák vannak, amelyeket a látványtól függően illik valamilyen 
tartalommal feltölteni. A letölthető példák között erre is talá- 
lunk megoldást. 


Titkosírás? 

végül egy essen pár szó a karakterkódolásról! Az XML techno- 
lógia, a W3C ajánlása szerint csak az UTF-8, és az UTF-16 kó- 
dolást támogatja. Fontos tudni, hogy azok az kódolások, ami- 
ket a fájlokba írunk (pl: encoding—"iso-8859-2" csak ajánlások 
az alkalmazások számára, a lényeg a fizikai fájl vagy stream 
kódolásán van. Ilyen ajánlás lehet az XML-deklarácóban. Ez 
XML-ben és az XSLT-ben is jelen lehet, és az XML-forráskódot 
megjelenítő alkalmazásnak szól. Lehet az xsl:output tagban. Ez 
írja le a transzformer objektum kimeneti streamjének kódolá- 
output html egyik META tagjában. Ez pedig a browseré. 

Ezek tehát csak ajánlások. Az igazi karakterkódolást a fájl vagy 
stream első bájtjai írják le, e néhány bájt neve BOM (Byte 


Order Mark), és értékei a következők lehetnek: 
HA UTF-8: - EF BB BF 
HA UTF-16 (Little Endian): — FF FE 
HF UTF-16 (Big Endian): — FE FF 


Mivel a BOM vagy jelen van, vagy nincs (alkalmazástól függ a 
jelenléte) a tényleges kódolás eldöntéséhez a W3C a követke- 
ző ajánlást teszi: ha jelen van a BOM, a kódolást az írja le. Ha 
nincs jelen, az "encoding? attributumból vegyük. Ha az sincs 
jelen, UTF-8-at feltételezzünk. Hát ez sajnos még így sem eg- 
zakt. Ha valami nincs a helyén, vagy nem egyértelmű, jobb 
esetben hibaüzenetet kapunk, rosszabb esetben értelmezhetet- 
len zagyvalék jelenik meg. Legjobban akkor járunk, ha az al- 
kalmazásunkban mindenhol betartjuk, hogy egyrészt a fájokat 
és streameket ellátjuk BOM-mal (a fájloknál mentés kódolás- 
sal, ezt még a Notepad is tudja, illetve a streameknél bizonyos 
property-k helyes beállítása), másrészt az "encoding" 
attributumokat is beállítjuk a BOM-nak megfelelő kódolásra. 
Erről a témáról egy nagyon jó cikk van az [enc] címen. 
Példák és végszó 

Mivel az XML technológia nem éppen szűkszavú kódokat 
eredményez, a cikkben írt példák többnyire csak részleteket 
tartalmaznak. Viszont az [XSLTFAJ] címről letölthető az összes 
teljes lista. Ugyanitt található két nagyon egyszerű alkalmazás 
(VB6, és C$) amelyekkel azokat a transzformációkat is meg le- 
het nézni, amelyeket az explorer nem mutat meg. 

Az XML technológiával nagyon sok irodalom foglalkozik. A 
Google az "XML szóra 18 millió találatot adott 0,04 sec alatt 
(szerintem nem számolt jól utána). Két cikk terjedelemben 
legfeljebb kedvcsináló-ötletadó terveink lehettek. Ha Önök 
közül néhányan kedvet kaptak a kísérletezésre, már elértük 
célunkat! 


Gyebrovszki Zoltán 
gzOsensenet.hu 





Szeretsz barkácsolni? 


Ha nem szeretsz barkácsolni és érezted már úgy, hogy jó 
lenne egy dobozos szoftver, ami segítene egységes intranet, 
extranet és internet alkalmazások fejlesztésében, akkor 


válaszd a Sense/Net Portal Engine-t! 


www.sensenet.hu/portalengine 
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[1-1 Exchange 1000 jogosultság: 
sz állítás kódból 


Az Exchange-fejlesztőknek mind pszichológiai, mind állóképesség szempontjából eddig is jóval 
edzettebbeknek kellett lenniük, mint kollégáiknak. A jogosultságállítás művelete is beleillik ebbe a 
képbe, bár kicsit csalóka, hogy az eleje pikk-pakk, elegáns, csak a vége felé vannak komoly megpró- 


báltatások. 


Az Exchange 2000 programozásának egyik legrejtettebb zuga 
a jogosultságállítás. Jogosultságot állíthatunk mappákon, doku- 
mentumokon, de meglepő módon a Microsoft eszközeivel 
csak a mappákon definiált jogokat érhetjük el, holott Exchange 
területen gyakran felmerülő probléma a dokumentumok egye- 
di jogosultságállítása. 

A dokumentumokon definiált hozzáférési jogok állítását eddi- 
gi tudásom szerint egyetlen termék támogatja (és ez sem régó- 
ta), melynek Store Explorer a neve. Akinek eddigi legfőbb vá- 
gya a dokumentumok jogosultságállítása volt, a cikkben megis- 
merheti a téma alapjait. 

Nem nagy ördöngösség, amit most bemutatok, de lesz benne 
minden: WebDav, XML, általános Windows 2000 és Exchange 
jogosultság-ismeretek. 


Jogosultságkezelési alapok 


Windows 2000 tartományba belépve a domain controller ge- 
nerál egy úgynevezett Access Tokent a felhasználónak, amely 
— többek között — tartalmazza a felhasználó SID-jét (Security 
Identifier), mint egyedi azonosítót. A felhasználó munkájának 
minden mozzanatát Access Tokenjének bemutatásával végzi, 
azaz minden processz futtatásához a Windows felhasználja a 
felhasználó SID-jét. Minden Windows 2000 Active Directory- 
ban tárolt felhasználóhoz és csoporthoz tartozik egy SID, 
amellyel hivatkozhatunk rá. A különböző erőforrások (pl. 
Exchange dokumentumok vagy mappák) hozzáférési definí- 
ciói SID-ek és a hozzájuk tartozó jogosultságok listáját tartal- 
mazzák. 

Az előbb írt hozzáférési definíciókat ACL-nek, azaz Access 
Control Listnek nevezzük. Az ACL-ek ACE-kből, azaz Access 
Control Entry-kből állnak, amelyek egy, azaz egy darab hozzá- 
férési jogot definiálnak, pl. Gézának olvasási joga van. 

Az ACL önmagában nem elég. Egy elem jogosultsági informá- 
ciói tartalmaznak további adatokat is. A teljes jogosultságleíró 
információt Security Descriptornak nevezzük. 


Mit lehet megtudni a Security Descriptorból? 


A descriptor a jogosultságok listáján kívül hordoz még pár fon- 
tos információt. Innen megtudhatjuk például, hogy melyik fel- 
használó az elem tulajdonosa, a tulajnak melyik az elsődleges 
csoportja, a descriptor, illetve a jogosultság lista hányadik ver- 
ziójával dolgozunk, melyik információ örökölt a szülő mappá- 
ról és melyik , saját", stb. 

Azt, hogy egy felhasználó jogosult-e olvasni az adott elemet, 
sajnos a Security Descriptor-ról nem tudjuk meg, hacsak ki 
nem értékeljük azt, ami igazából az Exchange dolga. Ebből az 
adathalmazból tipikusan a jogosultságállító dialóguson látható 
dolgokat tudhatjuk csak meg. 


A jogosultságleíró lekérdezése 


A jogosultságleírót az adott Exchange elem (akár mappa, akár 
nem) 


http: //schemas .microsoft . com/exchange/ 
$ security/descriptor 


mezője tartalmazza, ami vagy natív WebDav, vagy EXOLEDb 
(Exchange szerver oldali OLE Db provider) használatával kér- 
dezhető le (az MSDAIPP kliens oldali ADO provider sajnos 
nem támogatja). A következő WebDav-kérés a jogosultságlei- 
róval tér vissza: 


Content-Type: text/xml 
Depth: 0 
Translate: f 
c?xml version-"1.0"?5 
cpropfind xmlnsz"DAV:" 
xmlns:Sz"http: //schemas .microsoft . com/ 
$  exchange/security/": 
$£prop, cS :descriptor/:c/prop? 
£/propfind: 


A jogosultságleíró formátuma 


Az előbbi kérésünkre érkezett válasz egy szabványos WebDav 
response, amely (a fejléc és általános részeket lefejtve) a követ- 
kező (lényegtelen részek kipontozva): 


cga:prop? a 
cd:descriptor: 
cS:sSecurity descriptor 
xmlns:S-"http: //schemas .microsoft . com/ 
b  security/" 
S:from mapi tlh-"1"5 
cS:revision:1c/S:revision; 
cS:owner S:defaulted-"O"5 
cS:sids 
cS:String sid5S-1-5-...c/S:string sid: 
cS:typeruserc/S:type: 
cS:nt4 compatible namesMON 11 
MpDSystemc/S:nt4 compatible name: 


cS:ad object guid:(d95f88a3...)c/S:ad object guid: 


cS:display namesrMDSystemc/S:display names 
c/S:sids 
c/S:owner: 
cxcS:primary group S:defaulted-"O"5 
cS:Sid5...c/S:sid: 
c€/S:primary group: 
cS:dacl S:defaulted-"0" S:protected-"0" 
S:autoinherited-"1"5 
cS:revision52c/S:revision: 
cS:effective acesz 
cS:access denied ace S:inherited-"1"5 
cS:access maskofO7bfc/S:access mask: 
cS:Sids...c/S:sids 
c/S:access denied aces 


cS:access allowed ace S:inherited-"1"5 
SS:access masko:1fO7bfc/S:access mask: 
cS:Sid:...c/S:Sid: 
c/S:access allowed ace; 
c/S:effective acesz 
c/S:dacls 
c/S:Security descriptor: 
c/d:descriptor: 
£/a:prop? 


A leíró érdekes része az cS:security descriptorz és 
S/S:security descriptor: tag-ek között van (a továbbiakban a 
http://s"chemas.microsoft.com/security/ XML névteret csak ,,S:"- 
ként jelölöm, ahogy az a jogosultságleíróban is van), innen 
kezdődik a bonyodalom. Látható, hogy a cS:security descriptorz 
négy fő részre bomlik: 

TA cS:revisions: egy szám jelzi a jogosultságleíró ver- 

zióját 

TA cS:owner3: az elem tulajdonosáról tartalmaz informá- 
ciót (S:sid formátumban, erről később) 
cS:primary groupz: az elem tulajdonosának elsődle- 
ges csoporttagságáról hordoz információt (ez is S:sid 
formátumban, és erről is később) 
cS:dacl5: itt a lényeg, tartalmaz egy cS:effective acesz 
node-ot, és azon belül az előbb ismertetett ACL-t, itt ta- 
lálható a  jogosultságdefiníciók listája, azaz 
cS:access denied aces és cS:access allowed aces 
tag-ek sokasága, amelyeket hamarosan közelebbről 
megismerhetünk. Az cS:effective acesz node azokat a 
jogosultságdefiníciókat tartalmazza, amelyek magára 
az elemre érvényesek: ha mappa jogosultságát kérdez- 
zük le, előfordulhat itt még két másik ACL-típus: 
cS:subcontainer inheritable acesz - ez a mappánkban 
újonnan — létrehozott almappára, — míg az 
aS:subitem inheritable acesz az újonnan létrehozott 


dokumentumra , öröklődő" jogok listája. 


mA 


Az előbbi felsorolásban összegyűlt három XML node-típus, 
amire vissza kell térnünk, hát térjünk vissza: 

MH Az cS:sids: egy olyan struktúra, amivel egyértelműen 
azonosítunk egy Active Directory objektumot (jelen 
esetben felhasználót vagy csoportot, Exchange eseté- 
ben ezt a két Active Directory objektum-típus értelme- 
Zett). Láthatjuk, hogy a struktúra pl. egy felhasználónak 
nem csupán a SID-jét mint azonosítóját tartalmazza, 
hanem azon kívül minden más lehetséges információt, 
ami így sebtében érdekes lehet róla: a SID-je, a típusa 
(felhasználó, csoport, ,well known group" a beépített 
csoportok esetén, vagy ,alias", stb.), az NT4 
kompatibilis neve, a GUID-ja (Active Directory esetén 
ez alapján azonosítja egyértelműen az objektumot, de 
ettől függetlenül használja a SID-et is, ami az NT4 vi- 
lágból öröklődött), sőt még a képernyőn megjelenő ne- 
ve is. Amikor később a jogosultságleíróba beletúrunk, 
ugyanilyen struktúrában kell jeleznünk minden fel- 
használót/csoportot az Exchange-nek, azzal a kivétel- 
lel, hogy akkor elég a felhasználó egy tulajdonságát 
megadnunk (pl. a SID-jéD. 

Az cS:access denied aces és cS:access allowed aces 
node-okat neveztem a cikk elején ACE-knek, azaz 
Access Control Entry-knek. Ezek a node-ok egy jogo- 
sultságot reprezentálnak, azaz hogy Gézának olvasási 
joga van (vagy éppen tiltott). Ha belenézünk, láthatjuk, 
hogy nem tartalmaz mást, mint egy S:sid-et (amit az 
előző pontban megismertünk), valamint egy 


S:access mask-et, ami a jogosultsági szint 


7 


— 


hexában tárolt formája (lentebb megismerhet- 
jük ezt is). Ha jobb szzük, találunk IESS 
jük ezt is). Ha jobban megnézzük, találun az 


még egy infót, mégpedig egy ,S:inherited" 

néven futó attribútumot: ugyan mi lehet ez? ő 

mondja meg, hogy ezt a jogosultságot a szülőmappától 
örökölte az elem, vagy a , sajátja". 


Ezzel ki is végeztük a jogosultságleíró értékelését, ami első rá- 
nézésre talán ördöngösnek tűnt, de valójában nagyon egysze- 
rű művelet. 


Jogosultsági szintek 


A jogosultságleíró formátumában megismert cS:access mask: 
node által tartalmazott hexára konvertált bitmask az ACE jogo- 
sultsági szintjét írja le. Ahogy ebből kiderült, a jogosultsági 
szintet úgy kell összeállítanunk, hogy a különböző jogosultsá- 
gok értékeit AND kapcsolatba hozzuk egymással, majd ezt a 
hexa számot adjuk meg az cS:access mask3-nak. A jogosult- 
sági szintek három különböző táblázatba sorolhatók: az általá- 
nos jogosultsági szintek táblázatába: 





Hexadecimális azonosító 


ETTÉL T 














Delete 0x00010000 
Read Permissions 0x00020000 
Change Permissions 0x00040000 i 
Take ownership 0x00080000 űj 
Synchronize 0x00100000 








0x00000001 








List 

















ontents 
Create Item ———— 0x00000002 SE] 
Create Container 0x00000004 
Read Property 0x00000008 
Write Property 0x00000010 
Read Attributes 0x00000080 
Write Attributes —— OXOOOOO100 





A csak dokumentumokra vonatkozó jogosultságok táblázatába: 


a (2e e xgtt TE EZT LP HTT tő 


[ dAATTT ERT 






































Read Body 0x00000001 
Write Body 0x00000002 kár 
Append Message 0x00000004 
Read Property 0x00000008 
Write Property 0x00000010 
Execute 0x00000020 
Read Attributes 0x00000080 
Write Attributes 0x00000100 
Write Own Property 0x00000200 
Delete Own Item 0x00000400 
View Item 0x00000800 





Mappajogosultság esetén az általános plusz a mappára vonat- 
kozó jogosultsági táblán kell végigmenni és AND-elni a jogo- 
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sultságokat, dokumentum esetén pedig az általáno- 


son plusz a dokumentumra vonatkozón. 
a 


Jogosultságállítás 
A jogosultság állítása sem túlságosan bonyolult mű- 
velet, csupán két dolog kell hozzá: türelem és egy XML-parser. 
A türelem azért, mert az Exchange semmilyen módon nem je- 
lez vissza, ha valamit elrontottunk a fent ismertetett XML- 
dokumentum formátumában visszaküldéskor, az XML-parser 
pedig azért, mert nem elég XML-t írnunk, bogarásznunk is kell 
a lekérdezéskor megkapott értékben. A jogosultságokat 
ugyanis pontosan olyan formátumban kell visszaírnunk, mint 
amilyenben kaptuk, és amihez nem nyúlhatunk (pl. az örökölt 
jogosultságokhoz), azt is maradéktalanul vissza kell juttatnunk 
az Exchange-nek, így módosításkor az örökölt jogokat érdemes 
egy az egyben a lekérdezett adatból visszaküldenünk. A küldés 
(jogosultság property felülírás) előtt alaposan le kell ellenőriz- 
nünk a leíró tartalmát és formátumát. 
A példában szereplő — dokumentumra — adjunk a 
TITANIUMNGeza nevű felhasználónak olvasás jogosultságot. 
Lekérdeztük az Active Directory-ból, hogy Géza SID-je ,§-1-5- 
21-1482476501-2139871995-682003330-1115". Kiszámol- 
tuk, hogy a 0x120889 jog pont jó lesz Gézának, ezt a számot 
úgy kaptuk, hogy AND kapcsolatba hoztuk a következő jogo- 
kat: Read Permissions, Synchronize, Read Body, Read 
Property, Read Attributes, View Item. Így Géza azon felül, hogy 
teljes mértékben megtekintheti a dokumentumot, még szinkro- 
nizálhatja is. Ezzel meg is van minden szükséges informá- 
ciónk, már csak a következő formátumra kell hoznunk a be- 
gyűjtött adatokat: 
cS:access allowed ace S:inherited-"0" 5 

cS:access mask:120889c/S:access mask: 

cS:Ssid: 
cS:sString sid:5S-1-5-21...c/S:string sid: 
cSS:typeruserc/S:typez 
cS:nt4 compatible namer:TITANIUM Geza 
c/S:nt4 compatible names 


c/S:S8ids 
$/S:access allowed aces 


Következő lépésként készítsünk egy szabványos headert a jo- 
gosultságleírónknak: 


cS:security descriptor 

xmlns:§Sz-"http://schemas .microsoft.com/ security/" 
xmlns:D-"urn:uuid:c2f41010-65b3-11d1-a29f- 

$ 00aa00c14882/" 

D:dt-"microsoft.security descriptor"5 


Vegyük elő az XML-parserünket, szedjük ki az eredeti leíróból 
az cS:dacl5 node tartalmát (Xpath-szal egyszerűen "//S:dacV", 
majd az cS:dacl5 által tartalmazott cS:effective acesz végére 
biggyesszük oda az előbb előállított ACE-ünket (Gézának olva- 
sás joga van). Ha ezzel készen vagyunk, írjuk át az cS:dacls 


node "S:autoinherited" és , S:defaulted" értékét nullára (mivel 
ezeknek az attribútumoknak csak mappa esetében van értel- 
mük;), és el is készültünk a piszkos munkával. Munkánk ered- 
ménye egy cS.dacls node, amely tartalmazza az összes eddi- 
gi, valamint a Géza olvasási jogosultságát is. 

A következőkben már egyszerű, általunk jól ismert lépéseket 
végzünk: először összerakjuk az első lépésben gyártott 
headerünket és az előbb készített ACL-t, majd a végére tesszük 
a "c/S:security descriptor:" lezáró tag-et, így előállt a teljes jo- 
gosultságleírónk. Ezután már csak egy WebDav kérést kell 
összeállítanunk, amely elküldi a munkánkat az Exchange-nek, 
és már készen is vagyunk: 


Sa:pProp? 
cd:descriptor? 
cS:Security descriptor 
xmlns:S-"http: / /schemas .microsoft . com/ 
4. security/" 
S:from mapi tlh-"1"5 
cS:owner S:defaulted-"0"5...c/S:owner: 


cS:dacl S:defaulted-"0" S:protected-"0O0" 
$ S:autoinherited-"0"5 
cSS:effective acesz 
cS:access denied ace S:inherited-"1"5 
cS:access masko:fO7bfc/S:access mask: 
cS:Sid:...c/S:S8id: 
c/S:access denied acez 
cS:access allowed ace S:inherited-"1"5 
cS:access masko:1f0O7bfc/S:access mask: 
cS:Sids...c/S:s8ids; 
c/S:access allowed aces 
c/S:effective aces; 
cS:access allowed ace S:inherited-"0" 5 
cS:access mask:5120889-/S:access mask; 
cSS:S8ids 
cS:String sid:S-1-5-21... 
c/S:String sid: 
SS:typeruserc/S:type: 
cS:nt4 compatible namer:TITANIUMYGeza 
c/S:nt4 compatible names 
c/S:sid: 
c/S:access allowed aces 
c/S:dacls 
c€/S:sSsecurity descriptor: 
c/d:descriptor: 
§/a:prop? vi 


Jótanácsként megjegyzem, hogy — attól függetlenül, hogy az 
SPS 2001 WebsStore alapú, nem érdemes az SPS dokumentu- 
mainak jogosultságát a fent írt módon állítani, ez ugyanis a do- 
kumentum , teljes megsemmisülését" vonja maga után. 


Szabó Dávid, 
MCSD, vezető fejlesztő 
szabo.davidgmontana.hu 


ACADEMIA 


A NetAcademia Kft. felvételt hirdet 
munkakörbe. 


A konzulens feladatai: 


9 Előadások, tanfolyamok tartása Windows 2003 és egyéb témakörökből 
9 Szakcikkek, tanulmányok írása 

9 Szakfordítás angolról magyar nyelvre 

9 Atech.net magazin szakmai felügyelete 


Követelmények: 


09 Legalább egy MCP-vizsga követelmény, MCSA/MCSE-képesítés előnyt jelent 
9 Jó megjelenés, határozott fellépés 

9 A magyar nyelv hibátlan használata mind írásban, mind szóban 

9 MCSE-képzés elérése a próbaidő alatt 


Amit kínálunk: éji Miéü 


versenyképes fizetés, jó S TMŰNKETÉGKÖT ingyenes MCP-vizsgázás (sllleras vizsga esetén!), 
korlátlan tanulási lehetőség. 


Jelentkezéseket (fizetési igény megjelöléssel) a marcellfönetacademia.net címre várunk. 





A meghatározásokra 
adott válaszokat írja a 


0 és Ó stb. — más számok jelölik.) Helyes megfejtés ese- 
tén a kiemelt négyzetekbe került betűket felülről lefelé 





SZELETELO Mt r 
számoknak megfelelő sor- 


ba! Az ábrán belül a számok betűket rejtenek, ahol 
ugyanaz a szám mindig ugyanazt a betűt jelenti. 
(A rövid és a hosszú magánhangzókat - PI. I és Í, vagy 


Közkegyelem 


folyamatosan összeolvasva Szmolinka Rezső rejtvény- 
szerkesztő, a FeleSkandi rejtvényújság kiadójának gon- 
dolatát ismerheti meg. A kiadó elérhető: 

Tel/Fax.: 283-0109 TET ETET 
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saga ésREáo hivatalos Microsoft mérnök képzések 
2003-ban is! 
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A SZÁMALK Továbbképzés 2003-ban is tavalyi, változatlan nettó áron kínálja hivatalos 
Microsoft tanfolyamaira épülő Microsoft rendszeradminisztrátori (MCSA), rendszermér- 
nöki (MCSE) képzéssorozatait. A tanfolyamokat követően lehetősége van vizsgákat 
tenni Prometric vizsgaközpontunkban és megszerezni a nemzetközileg elismert okle- 


velek valamelyikét. 


MCSE (rendszermérnök) képzés 
az öt kötelező vizsgához 


július 7-től, 

430.000 helyett már nettó 399.000 Ft-tól!!! 

Nagy, összetett informatikai rendszereket és hálóza- 
tokat üzemeltető szakemberek képzése, akiknek fela- 
datuk lesz Windows 2000 alapú hálózatok teljeskörű 
adminisztrálása és támogatása, informatikai infra- 
struktúrák tervezése. 


Válassza ki az Önnek mesgfélélő 
minősítést és képzési konstrukciót! 


Hivatalos Microsoft tanfolyamokra épülő, rugalmas beosztású, kedvezményes konst- 
rukciójú és árú képzéssorozatok. Különböző segédanyagokat, vizsgafelkészítő anya- 
gokat tartalmazó oktatási konstrukciók és csomagok. Kedvezményes tanfolyami 

lehetőségek a szabadon választható vizsgára felkészítő tanfolyamokra. 
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MCSA (adminisztrátor) képzés 
a kötelező vizsgákhoz 


július 7-től, 

270.000 Ft helyett már nettó 229.000 Ft-tól! 

A kisebb informatikai rendszereket és hálózatokat 
üzemeltető szakemberek számára ajánljuk, akiknek 
feladatuk lesz Windows 2000 alapú hálózatok 
telepítése, konfigurálása, adminisztrálása, karbantar- 
tása. a 
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